PLATOTerm for Atari - Working out tgi and ser issues.

[tschak909]

approx 2000 bytes for scaling in both directions (convert 512x512 to 320x192 and back again). Did it this way to get a modicum of speed in the line draw, and because I'm not that great at doing 6502 routines for dividing/multiplying 16-bit integers in clever ways.

 

-Thom

[sanny]

here you are...

mulfuncs.s

[tschak909]

Thanks. will fold these in today.

 

-Thom

[tschak909]

Yup, that worked, but the Y coordinate is inverted. (everything being rendered upside down) I need to invert the Y values...

 

-Thom

[tschak909]

Yup, XOR'ing 511 was sufficient.. going to see if i can trim some more fat.

 

-Thom

[tschak909]

Currently weighing in at 16294 bytes. whee. but adding prefs and touch will grow it more..

 

-Thom

[flashjazzcat]

Why does CC65 redirect the VBI to a handler inside of the application, exactly?

[tschak909]

I just did an experiment and used the atari-cart target, and it does indeed fit inside a 16K cartridge but it crashes when it tries to open the serial port so am guessing the cc65 ser driver would need to be modified a bit to work in a cartridge, but still, very interesting. Especially from a memory perspective.

 

 

(This initially had a question, but deleted because I answered it a few moments later)

 

 

-Thom

Edited August 21, 2018 by tschak909

[sanny]

I just did an experiment and used the atari-cart target, and it does indeed fit inside a 16K cartridge but it crashes when it tries to open the serial port so am guessing the cc65 ser driver would need to be modified a bit to work in a cartridge, but still, very interesting.

Very cool.

 

Did you use a statically linked serial driver, or load it at runtime?

 

I guess you didn't include any mouse drivers, did you? Did the original PLATO cart support mouses/joysticks? Or the original PLATO terminals? If not, maybe leave mouse support out completely.

 

regards,

chris

[sanny]

Why does CC65 redirect the VBI to a handler inside of the application, exactly?

 

Does this answer your question?

 

 

The mouse drivers use an IRQ (timer to poll the ports). In the serial driver it's an artifact how the machine-independent parts of the cc54 runtime work (all, most at least, of the serial drivers for the other machine need interrupts).

[tschak909]

(1) I statically linked in the serial driver. but it crashes, will dig down and see if it's during install or open.

(2) Nope I didn't. The original PLATO terminals have touch screens, and the Atari cartridge handled this with joysticks and a P/M cross cursor. The big improvement here is that PLATOTerm emits Fine Grained Touch codes, which were added later, to send coordinates for every pixel on the display, instead of just a 16x16 grid. It would be interesting to add it, as it enhances the experience, but it isn't necessary.

 

-Thom

[sanny]

Ok.

 

So 1) is something to check out.

 

Re 2), yes, mouse support should be included.

 

So how far are you away from a feature complete implementation? Will there come in much more code? If not it would be interesting to maybe convert some C functions to assembly in order to save space, and create a cartridge of the final version.

 

regards,

chris

[tschak909]

The terminal is feature complete. Save for touch and prefs.

 

I removed the prefs and touch code to make this diet version.

 

Prefs is basically a place where you could select:

 

Driver - well, there's only one for Atari so, not needed.

Baud - Right now we're locked at 1200bps, unless I can implement some form of hardware flow control for R: devices that can do it (this currently means Black box and MIO, 850 is a lost cause due to severe hamstrings in the way RS232 is hooked up!). This is a topic for another conversation.

Touch Driver

Save prefs to disk. This also saved the current color palette.

Exit - applied prefs.

 

 

On a slightly related note:

 

I did initially try, at Oliver's request, to fold in IP65 support, but the size of the stack ballooned every one of my targets, and the text routines aren't fast enough yet, so TCP retransmissions were constantly happening, connection would eventually hang. Oliver and I went back and forth on this for two weeks. Also, lack of TCP receive window shrinking is a serious problem because PLATOTerm has significant processing bottlenecks, flow control is required for TCP. IP65 support has now been completely excised from PLATOTerm until further notice.

 

-Thom

[flashjazzcat]

 

Does this answer your question?

 

It does, but I had no idea the question had been asked and answered on the prior page.

[sanny]

It does, but I had no idea the question had been asked and answered on the prior page.

 

Maybe it could be removed from the machine-independent parts. Don't know how the main cc65 maintainer feels about it (would required some #ifdefs), and I myself only recently became aware of this probem with Thom's problems. Would help for serial drivers, but not for mouse drivers.

 

regards,

chris

[flashjazzcat]

CC65 was a 40K 6502 executable the last time I used it (in 1995 or so), so I'm talking out of my ass for the most part. But the matter of not being able to link position-critical code to a specific address range seems quite problematic to me at first sight. I'm almost certain there was no way to do this in the compiler I used to use, but I didn't particularly mess with interrupt handlers in those days and there was no mouse driver back then (although I was using SDX with 'USE BANKED'). It's easy in assembly language, of course, to keep interrupt handlers the Hell out of the way of banked RAM and ROM, but I wouldn't want to presume this is an easy thing to achieve in CC65.

[sanny]

CC65 was a 40K 6502 executable the last time I used it (in 1995 or so), so I'm talking out of my ass for the most part.

 

Hmm, then you were using and are thinking of the "old" CC65 of Dave Dunfield. The current version originated from it (I think most of the compiler itself is still much of his code), but the things surrounding it (assembler, linker, runtime library) had been rewritten from scratch completely.

The current version doesn't work natively on the Atari anymore, since it's much too big. It's strictly a cross-compiling environment.

 

But the matter of not being able to link position-critical code to a specific address range seems quite problematic to me at first sight. I'm almost certain there was no way to do this in the compiler I used to use, but I didn't particularly mess with interrupt handlers in those days and there was no mouse driver back then (although I was using SDX with 'USE BANKED').

 

One can link to a specific address by using a modified linker script. It's not that straightforward, and always a bit of a hassle, but it can be done.

 

regards,

chris

[flashjazzcat]

The current version doesn't work natively on the Atari anymore, since it's much too big. It's strictly a cross-compiling environment.

Oh - I didn't imagine the x86 executable would work on the A8, no. But it's interesting that the compiler still has some of the original code. I really wanted to rewrite the IO code on the native CC65 compiler (although this would have involved rebuilding the whole thing, which was far too intimidating at the time), since the single byte get/put was SO slow under SpartaDOS X with the library disabled (you can read about the reasons behind this - which concern 'minibuffers' - in the SDX manual).

[sanny]

Oh - I didn't imagine the x86 executable would work on the A8, no. .

No, sure . I didn't intend to imply that. But also you cannot compile the cc65 source code by itself to get an Atari-hosted version. Much too big...

 

To recompile the whole thing on Windows, Linux, or MacOS is a breeze. Just type "make"

[flashjazzcat]

I'd like to grab Dave's original source and recompile it with some IO optimisations, but frankly it's one of those things I'll never get around to. Anyway: sorry for going off on a tangent of nostalgia.

[sanny]

On a slightly related note:

 

I did initially try, at Oliver's request, to fold in IP65 support, but the size of the stack ballooned every one of my targets, and the text routines aren't fast enough yet, so TCP retransmissions were constantly happening, connection would eventually hang. Oliver and I went back and forth on this for two weeks. Also, lack of TCP receive window shrinking is a serious problem because PLATOTerm has significant processing bottlenecks, flow control is required for TCP. IP65 support has now been completely excised from PLATOTerm until further notice.

 

An IP65 version would be fine. Disregarding the problems of the TCP window size, I think it might be better to create two versions of PLATOterm, one for serial and one for ethernet. Not one EXE covering it all.

 

regards,

chris

[sanny]

I had an idea in the meanwhile. But I have to check before...

 

In order to reproduce, when I take your latest git version (4336fad970ae7414c4581e876c1ff75df4ba0c89) and disable the "#ifdef __ATARI__" where the mouse drivers get statically linked, am I getting a version which again loads the drivers dynamically? Where you did see the problem?

 

Hi Thom,

 

could you download the latest CC65 source code and compile it with the following changes?

diff --git a/cfg/atari.cfg b/cfg/atari.cfg
index 4680a89e..8cb57031 100644
--- a/cfg/atari.cfg
+++ b/cfg/atari.cfg
@@ -55,6 +55,6 @@ FEATURES {
     CONDES: type    = interruptor,
             label   = __INTERRUPTOR_TABLE__,
             count   = __INTERRUPTOR_COUNT__,
-            segment = RODATA,
+            segment = LOWCODE,
             import  = __CALLIRQ__;
 }
diff --git a/libsrc/runtime/callirq.s b/libsrc/runtime/callirq.s
index 74a12c4d..f5e4940f 100644
--- a/libsrc/runtime/callirq.s
+++ b/libsrc/runtime/callirq.s
@@ -47,7 +47,11 @@
 ; ignore this at will.
 ; NOTE: The routine must not be called if the table is empty!
 
+.ifdef __ATARI__
+.segment "LOWCODE"
+.else
 .data
+.endif
 
 callirq:
         ldy     #.lobyte(__INTERRUPTOR_COUNT__*2)

And change the atari.cfg of platoterm accordingly:

diff --git a/src/atari/atari.cfg b/src/atari/atari.cfg
index 1d2e818..8ed5def 100644
--- a/src/atari/atari.cfg
+++ b/src/atari/atari.cfg
@@ -55,6 +55,6 @@ FEATURES {
     CONDES: type    = interruptor,
             label   = __INTERRUPTOR_TABLE__,
             count   = __INTERRUPTOR_COUNT__,
-            segment = RODATA,
+            segment = LOWCODE,
             import  = __CALLIRQ__;
 }

(Don't know why you are using a local atari.cfg when all the changes you did there can be specified on the command line at link time.)

 

Then check if the SDX problem still persists. Your program is big enough that the heap starts after $7FFF. So dynamically loaded drivers shouldn't go to the $4000..$7FFF window. In the future if you are able to shrink the program, look in the linker map for __MAIN_LAST__. If it is above $7FFF, you're safe for loading dynamic drivers.

 

regards,

chris

[tschak909]

Ok, have applied the patches, and am building cc65 and will build platoterm to test. (I was finisihng up the 8x6 font and testing the screen output of the Atari ST port, just now got to a pausing point).

 

-Thom

[tschak909]

Wow, that worked out great! There's a slight bug where there's a visible player/missile with some garbage data (looks like a slight overlap of P/M with program memory). Will attach a dist binary here:

 

(replaced with a better build below)

 

But this works great under SDX, Ultimate1mb at 1088K touch and all. (currently testing with 850) Going through the hardware gamut now.

 

To run under SDX:

* Start your RS232 handler

* X AUTORUN.AR2

 

Otherwise, the disk boots automatically, as it's a MyDOS disk.

 

Anyone else seeing a different result with the above build?

 

Thanks, Chris! *hug*

 

-Thom

Edited August 22, 2018 by tschak909

[tschak909]

p.s. was able to work around the garbage p/m by moving it off the screen (HPOSP2). I didn't want to erase its data, because it might be valuable program data!

 

-Thom