Jump to content
IGNORED

PLATOTERM Cart last squeeze, need help


tschak909

Recommended Posts

I want to try and get the PLATOTERM cart out:

 

The problem is, right now, I am having to put one touch driver in at a time, and statically build to produce the output ROMs.

 

This works fine for no mouse, and the Koala pad and Joystick versions.

 

HOWEVER,

 

The amiga, st, and trakball (CX80) versions, which use the same common code, are a bit too big to fit into the rom, they overflow the 16K address area by an average of 128 bytes.

 

I need some help to try and squeeze out as much fat as I can, to make it fit, so that I can go on to the next phase, which is, "how in the hell do I package these onto a bank switched cartridge?"

 

I am very much swamped, trying to maintain TWO DOZEN ports of PLATOTERM, and this is getting out of my scope to the point where I am drowning trying to do this all myself.

 

Could I get a pair of eyes to look at the atari_cart branch of platoterm64 and see what can be done to squish this into 16K for all touch targets?

 

Code here:

https://github.com/tschak909/platoterm64/tree/atari_cart

 

The touch drivers are swapped in by changing the mouse driver in the mouse_install() call in src/touch_base.c

 

-Thom

 

Link to comment
Share on other sites

Hi Thom,

 

I don't have time to actually look at the source, but the most general way of solving the problem would be to compress the content on the ROM and unpack it into the RAM. This will work on any platform and many cartridge types allow disabling the cart after that, so you don't even lose RAM. A good lower estimate is ZIP, so PLATOTERM-1.2-Atari-cart-No-Mouse-FASTIO.rom (16k) becomes 10.2k zipped, plenty of space for unzip and more code.

 

- Peter.

Link to comment
Share on other sites

53 minutes ago, JAC! said:

Hi Thom,

 

I don't have time to actually look at the source, but the most general way of solving the problem would be to compress the content on the ROM and unpack it into the RAM. This will work on any platform and many cartridge types allow disabling the cart after that, so you don't even lose RAM. A good lower estimate is ZIP, so PLATOTERM-1.2-Atari-cart-No-Mouse-FASTIO.rom (16k) becomes 10.2k zipped, plenty of space for unzip and more code.

 

- Peter.

not only that, but then you don't need to cut features out either, the savings from compression usually far out-way the space needed to add the de-compressor within the cart as well.

Link to comment
Share on other sites

On 9/13/2019 at 8:28 PM, tschak909 said:

Could I get a pair of eyes to look at the atari_cart branch of platoterm64 and see what can be done to squish this into 16K for all touch targets?

 

Is it correct that the last commit to this branch was on May-14-2019?

 

I'm getting a build error there:

 

[blasi:~/atari800/platoterm64]$ make
cl65 -t atari --start-addr 0x2420 -Wl -D__RESERVED_MEMORY__=0x2000 --mapfile plato.map -o plato.atari -C src/atari/atari.cfg obj/atari/screen_base.o obj/atari/protocol.o obj/atari/terminal.o obj/atari/keyboard_base.o obj/atari/plato.o obj/atari/io_base.o obj/atari/touch_base.o obj/atari/mulfuncs.o obj/atari/terminal_char_load.o obj/atari/touch.o obj/atari/screen.o obj/atari/io.o obj/atari/font.o obj/atari/keyboard.o obj/atari/cartinit.o obj/atari/click.o obj/atari/cartstart.o obj/atari/screen_beep.o obj/atari/fast_text.o
ld65: Error: Duplicate external identifier: '__RESERVED_MEMORY__'
Makefile:311: recipe for target 'plato.atari' failed
make: *** [plato.atari] Error 1
[blasi:~/atari800/platoterm64]$

 

Strange. I think I was able to compile it successfully months ago.

 

regards,

chris

Link to comment
Share on other sites

15 minutes ago, _The Doctor__ said:

not only that but what is the full feature version that was started towards cart use but didn't have anything taken out yet?...

selecting what exact revision you want turned into a cart would be helpful for anybody looking to be helpful

The current repo that is in the atari-cart branch, as I had in the link above.

and yes, that is correct. odd that __RESERVED_MEMORY__ duplicate identifier is biting you there, it is a warning on mine.

 

-Thom

Link to comment
Share on other sites

With your change you don't reserve any memory anymore. But you are using GRAPHICS 8. I'm not sure this is correct. If you need to reserve memory, you can change your atari.cfg file either to put the value there, or make the symbol weak and do it like before on the linker command line.

 

I've noticed that the atari-cart.cfg in cc65 also doesn't declare it as "weak". I wrote the original version and I don't remember why I did change it to non-weak. Maybe that's also wrong in cc65.

 

I've managed to build a version with ST mouse support (which had the biggest overflow in my test) with a modified cc65 runtime library.

I did this change:

diff --git a/libsrc/atari/tgi/atr8.s b/libsrc/atari/tgi/atr8.s
index 7d2a6386..f4ff8a09 100644
--- a/libsrc/atari/tgi/atr8.s
+++ b/libsrc/atari/tgi/atr8.s
@@ -80,4 +80,5 @@ loop:   lda     (ptr1),y
         rts
 .endproc
 
+USE_CIO_LINE = 1
 .include "atari_tgi_common.inc"

 

This changes atari_tgi_common.inc to use the ROM to draw lines instead of using its own implementation.

 

Caveats:

  • it's not documented (I found nothing)
  • it has not been tested much, I think, since no one knows about this knob. Therefore using it will require some testing sessions.

 

regards,

chris

Link to comment
Share on other sites

On 9/13/2019 at 8:28 PM, tschak909 said:

I need some help to try and squeeze out as much fat as I can, to make it fit, so that I can go on to the next phase, which is, "how in the hell do I package these onto a bank switched cartridge?"

If "protocol.c" is also part of the Atari target (had only a brief examination) and not only for the C64 (like the header suggests) you can save ~60 bytes easily:

 

static padByte PTAT0[128] = {	/* PLATO to ASCII lookup table */
  0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,	/* original mapping */
  0x38, 0x39, 0x26, 0x60, 0x0a, 0x5e, 0x2b, 0x2d,
  0x13, 0x04, 0x07, 0x08, 0x7b, 0x0b, 0x0d, 0x1a,
  0x02, 0x12, 0x01, 0x03, 0x7d, 0x0c, 0x83, 0x85,
  0x3c, 0x3e, 0x5b, 0x5d, 0x24, 0x25, 0x5f, 0x7c,
  0x2a, 0x28, 0x40, 0x27, 0x1c, 0x5c, 0x23, 0x7e,
  0x17, 0x05, 0x14, 0x19, 0x7f, 0x09, 0x1e, 0x18,
  0x0e, 0x1d, 0x11, 0x16, 0x00, 0x0f, 0x87, 0x88,
  0x20, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
  0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
  0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77,
  0x78, 0x79, 0x7a, 0x3d, 0x3b, 0x2f, 0x2e, 0x2c,
  0x1f, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
  0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
  0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57,
  0x58, 0x59, 0x5a, 0x29, 0x3a, 0x3f, 0x21, 0x22
};

static padByte PTAT1[61] = {
  0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,	/* flow control mapping */
  0x38, 0x39, 0x26, 0x60, 0x09, 0x5e, 0x2b, 0x2d,
  0x17, 0x04, 0x07, 0x08, 0x7b, 0x0b, 0x0d, 0x1a,
  0x02, 0x12, 0x01, 0x03, 0x7d, 0x0c, 0x83, 0x85,
  0x3c, 0x3e, 0x5b, 0x5d, 0x24, 0x25, 0x5f, 0x27,
  0x2a, 0x28, 0x40, 0x7c, 0x1c, 0x5c, 0x23, 0x7e,
  0x97, 0x84, 0x14, 0x19, 0x7f, 0x0a, 0x1e, 0x18,
  0x0e, 0x1d, 0x05, 0x16, 0x9d
};

...
  else
    {
	theKey = PTAT0[theKey];
	if (FlowControl && theKey < 61)
      theKey = PTAT1[theKey];
...

I guess with some more efforts you could get rid of the second table completely, as it's mainly redundant - but it also depends on the performance constraints of "Key (padWord theKey)"...

Edited by Irgendwer
Fixed error in code
Link to comment
Share on other sites

I've put togther this as ready to run example for deflate/inflate compressing and starting a single-segment XEX starting at $2000 into a 16K plain ROM. 
https://www.wudsn.com/productions/atari800/platotermrom/platotermrom.zip

;
;    @com.wudsn.ide.asm.outputfileextension=.bin
;
; inflate is 508 bytes of code and constants
; inflate_data is 765 bytes of uninitialized data
; inflate_zp is 10 bytes on page zero

inflate_zp = $f0

target    = $2000

    org $7800
    .use main.inflate
    icl "Inflate-Data.asm"

    org $8000
    opt h-f+

    .proc main

    mwa #source inflate_zp
    mwa #target-6 inflate_zp+2

    jsr inflate
    
    jmp target

    .proc inflate
    icl "Inflate.asm"
    .endp

    .local source
    ins "Platoterm.xex.deflate"
    .endl
    
    .echo "Original executable file is ", .filesize "Platoterm.xex", " bytes"
    .echo "Deflated executable file is ", .len source, " bytes"
    .endp


    org $bff9
init    rts

    .word main
    .byte 0,4
    .word init

 

  • Like 1
Link to comment
Share on other sites

21 hours ago, tschak909 said:

>Coincidentally, I've managed to fit each touch driver into 5 ROM images, all fitting within 16K. :)

 

 

Well, but having so many different cartridge versions (even though the easy path for the currently build) should not be the target in my opinion. Having a single version which lets you switch input devices on the fly would be much more convient and the with compression, that should be easy to achieve.

And with the additional space gained, you could even have the option to install one or more R: drivers from Platoterm without having to load from a DOS.

Link to comment
Share on other sites

Well I'm not interested in the cartridge stuff, but I did pull down the 1.3 disk version from github. I'll probably tinker with porting it to assembler over the winter, when I'm bored with whatever else I'm working on. Hopefully you're done with making major revisions to the code base.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Alfred said:

Well I'm not interested in the cartridge stuff, but I did pull down the 1.3 disk version from github. I'll probably tinker with porting it to assembler over the winter, when I'm bored with whatever else I'm working on. Hopefully you're done with making major revisions to the code base.

I know the code exceedingly well, and can answer any questions.

 

This is part of why I compulsively publicly release all of my source code, so that others can make it better.

 

Case and point: 

How many versions of AMODEM were there? (I stopped counting at roughly two dozen, and some of them had amazing features) ;)

 

 

Link to comment
Share on other sites

If you have 16K carts that bank the lower 8k only, you could (in theory) build version with each driver in a different bank.  Have another bank with the BOOT logic: try to load a specified config file, if that fails, get config info input from user then set the bank for the selected input device.

 

That would avoid having to do any bank selects other than the initial, as driven by either the config or manual input.

 

Is that confusing?  Then view it this way, assuming a 64K cart

 

$A000-BFFF: 8K: MAIN - Always resident

$8000-9FFF: 8K: BOOT - loads the Config or, if not present, gets the config info from the user (gives option to save); after either, jump to the appropriate handler

$8000-9FFF: 8K: Joystick - joystick handler and any residual code fitting in 16K combined

$8000-9FFF: 8K: Touch Tablet - per above

$8000-9FFF: 8K: ST Mouse

$8000-9FFF: 8K: Amiga Mouse

$8000-9FFF: 8K: Other device

$8000-9FFF: 8K: Other device

 

 

Link to comment
Share on other sites

  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...