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