On Friday, 3 August 2018 23:37:07 UTC+10, alvalongo  wrote:
> Hi Daniel, congratulations for this work.

Heya!  Thanks!


> I been looking the source code of c64client.s, it's very large.
> 
> what source code editor do you use?

Yes, its gotten very large and almost monolithic.  I do intend on fixing that. 
I have already marked out where I need to break the source up.  1100 A4 pages
in the old listing format with a normal font.  Not a bad effort!

I use SciTE but in plain text mode.  In whatever editor you decide on using,
you'll want to use a mono-spaced font and tabs set to 8 spaces.

I did make a patch for EMacs so that it can deal with my files in its ASM mode
because someone else was using it to edit my files (with my specific
indenting).  I can provide this patch if you require it.


> 1-Why write floating point routines if they already exist on ROM?
> For example I write an application for GEOS-64 using geoProgrammer to plot 3D
functions, using the floating point routines in ROM.

I needed to reclaim the other 7KB or so of memory you get by switching out the
BASIC ROM.  I couldn't afford to keep the ROM just for the floating point
routines.  I currently have only 3KB of free memory or so after switching out
all the ROMs...  I'm 
pretty happy to have some Woz code in my game...


> 2-Why doesn't use the natural PETSCII characters through CHROUT kernal
routine?

Ummm...  Is this in the bootstrap/init or for the whole game?  I needed to draw
the characters in my own way and without the line-breaking functionality.  And
I always suspected that I'd need to drop the Kernal ROM, too.

In the early init, it seemed to be just as much code to directly write the
characters to the screen as it was to use the Kernal so I just used my own
routine.  I use Pascal-style strings...


> Suggest:
> 1-In "initDataLoad" section, load the X register with the last device used.
> For example on VICE for c64 I have the device 9 pointing to a Windows/MSDOS
directory
> I can load the "c64client" but fails to load the other files.

Yes, that would probably be a good idea.  At the moment, the game has to be run
from drive 8.  There is no error handling on the file load, either.  Terrible.


> 2-The drivers for mouse and joystick on external files

Hmm...  I'm not sure...  If I do that, I'd need to reserve specific memory for
it and "high memory" has only 700 bytes free or so in total if I consolidate
the areas and pair-back the actions cache/heap to whats actually minimally
required.

I guess I could do so but I didn't want any more loading after the initial
load, either.

It may happen but will need to wait until later.  I have to disentangle the
device driver code from the IRQ handler as well.

> bye
> alvalongo


See you!  Thanks for looking at the code!  I've been the sole developer and I
probably need another pair of eyes on the source...

 
> P.S. It will take me a while to fully understand the source because this ar65
assembler has some advanced features geoProgrammer doesn't have like "struct"

Yes, I'm using it because it seems to be the best in terms of what it can do
and the syntax is not confused with strange symbols.  I'm not even using it to
its fullest potential, just in its "none" target mode.

I've started the process of fully documenting the code now, too.  All of the
new routines have good commenting but the older ones are a little dry.  My
apologies.  I have tried to use meaningful names for everything, though.

Structs are just a way of declaring scope-bound constants (the offsets).  Quite
handy.


Daniel.


Oh!  Feel free to contact me directly if you like, instead of going through the
newsgroup.  I think my address is "discoverable".  I'll add it to the readme
soon, anyway.

--- SoupGate-Win32 v1.05