tschak909 Posted September 13, 2019 Share Posted September 13, 2019 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 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted September 15, 2019 Share Posted September 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 15, 2019 Share Posted September 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 15, 2019 Author Share Posted September 15, 2019 Great, I've never done that before. Can somebody point me in the right direction, or take a whack at it? I really have been going flat out for two years writing code for over two dozen platforms, and I could use some extra hands. -Thom Quote Link to comment Share on other sites More sharing options...
sanny Posted September 16, 2019 Share Posted September 16, 2019 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 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 16, 2019 Share Posted September 16, 2019 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 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 16, 2019 Author Share Posted September 16, 2019 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 Quote Link to comment Share on other sites More sharing options...
sanny Posted September 16, 2019 Share Posted September 16, 2019 (edited) I'm using latest cc65. And, in fact, the error is correct. It's not declared "weak" in src/atari/atari.cfg. Edited September 16, 2019 by sanny 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 16, 2019 Author Share Posted September 16, 2019 There we go, fixed that in latest commit. -Thom Quote Link to comment Share on other sites More sharing options...
sanny Posted September 16, 2019 Share Posted September 16, 2019 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 Quote Link to comment Share on other sites More sharing options...
sanny Posted September 16, 2019 Share Posted September 16, 2019 and, I forgot, it might be much slower... Quote Link to comment Share on other sites More sharing options...
+Stephen Posted September 17, 2019 Share Posted September 17, 2019 55 minutes ago, sanny said: This changes atari_tgi_common.inc to use the ROM to draw lines instead of using its own implementation. Pretty sure this will be an issue - I think there was some work done to just make it work at 1200baud or maybe 2400. Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted September 17, 2019 Share Posted September 17, 2019 (edited) 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 September 17, 2019 by Irgendwer Fixed error in code Quote Link to comment Share on other sites More sharing options...
+JAC! Posted September 21, 2019 Share Posted September 21, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 22, 2019 Author Share Posted September 22, 2019 (edited) Cool, I'll mess with this a bit. Coincidentally, I've managed to fit each touch driver into 5 ROM images, all fitting within 16K. Edited September 22, 2019 by tschak909 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted September 22, 2019 Share Posted September 22, 2019 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. Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 22, 2019 Author Share Posted September 22, 2019 (edited) If somebody wants to take a whack at doing that, awesome, the code is available. http://github.com/tschak909/platoterm-atari-cart/ -Thom Edited September 22, 2019 by tschak909 Quote Link to comment Share on other sites More sharing options...
Alfred Posted September 22, 2019 Share Posted September 22, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
tschak909 Posted September 23, 2019 Author Share Posted September 23, 2019 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) Quote Link to comment Share on other sites More sharing options...
+David_P Posted September 23, 2019 Share Posted September 23, 2019 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 Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted February 6, 2021 Share Posted February 6, 2021 Bumping this, are we any closer to a cart release yet? Quote Link to comment Share on other sites More sharing options...
tschak909 Posted February 6, 2021 Author Share Posted February 6, 2021 FujiNet basically stopped this. -Thom Quote Link to comment Share on other sites More sharing options...
Mr Robot Posted February 7, 2021 Share Posted February 7, 2021 Oh that's a shame. This would have been a lovely collectable cart. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.