+TheBF #1151 Posted January 3 30 minutes ago, Willsy said: If you got the double byte thing from TurboForth, know that I got it from the original driver/utility routines supplied by the original SAMS guys (the names of whom escape me right now) - there was a bunch of machine code source files supplied on disk and I simply copied the technique. ☝️ I think I used the same document and I looked at TF. Seemed like a consensus. Quote Share this post Link to post Share on other sites
+Ksarul #1152 Posted January 3 That double-byte thing is a function of the 74LS612 page selection routine. The odd address byte is written first (and is basically lost on 1M and smaller boards, but is meaningful with the 4M and larger implementations). The even byte then sets up the selection registers within the 256 pages of a 1M card. One note: yes, 4M SAMS cards do exist (that capability is one hardware revision past the cards I've sold in the past), but getting the memory chips that support it is getting seriously difficult/expensive. Lately, they've been about $100 for two chips and no guarantee they work as they're pulls (usually work) or fakes from China (often fail). That's double what they cost when I started looking to increase the memory size in 2016. @FALCOR4 has built a couple of them using the 2M chips and verified the operation in 4M mode, as have I. Any boards I sell in the future will have the capability to be expanded to 4M (switch the jumpers and install 2M chips), but will be delivered in the 1M configuration to ensure delivery of functional cards at reasonable cost. Though it is "technically" possible to upgrade the older 1M boards, it requires some significant board surgery and isn't generally advisable for those with limited soldering skills. 4 2 Quote Share this post Link to post Share on other sites
+RXB #1153 Posted January 3 8 hours ago, retroclouds said: I wasn’t aware there are any SAMS boards out there that have DSR memory. Did I miss something? Buy yeah, I also wondered how SAMS is able to do an initial mapping of SAMS pages itself upon startup. Well my SAMS 1 Meg card never needed to be Initialized it defaulted to pass mode 2,3,A,B,C,D,E,F like it was supposed to as 32K card And in Map mode defaulted to 2,3,A,B,C,D,E,F unless you changed a Register. So if you changed say 2 and 3 to 45,46 it would stay there on 45 and 46 even if you powered down the Console but did not turn off P-box. So upon restart of Console it would default back to Pass mode and 2 and 3, thus only when you switched to Map mode did you get 45 and 46. Quote Share this post Link to post Share on other sites
+RXB #1154 Posted January 3 8 hours ago, retroclouds said: I wasn’t aware there are any SAMS boards out there that have DSR memory. Did I miss something? Buy yeah, I also wondered how SAMS is able to do an initial mapping of SAMS pages itself upon startup. Sorry there is a misunderstanding. The SAMS memory card uses DSR space for the Mapper mode and Pass mode and is accessed with CRU just like any DSR. Quote Share this post Link to post Share on other sites
+RXB #1155 Posted January 3 On 1/3/2021 at 5:29 AM, TheBF said: Rich, I have been feeling my way along with the same SAMS card as Wolhess in my Forth project. What I noticed was that on Classic99 which has a 32Mb SAMS card I can run my SAMSINI routine only with a single byte as the page number, for example: >1F00, incrementing the pages by adding >0100. But on the real hardware I have to use a double byte. (>1F1F) At least this is what seemed to work. I didn't dig any deeper than that. Yea I never have used any address but >4000 up, so I never have used >5FFE address to change any Pages or Banks. And by Pages I mean first byte is Page and second byte is Bank. Quote Share this post Link to post Share on other sites
+RXB #1156 Posted January 3 3 hours ago, Willsy said: If you got the double byte thing from TurboForth, know that I got it from the original driver/utility routines supplied by the original SAMS guys (the names of whom escape me right now) - there was a bunch of machine code source files supplied on disk and I simply copied the technique. ☝️ My entire Machine Code is here: *********************************************************** * CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE AMSCRU * *********************************************************** * * AORG >8300 AMSCRU DATA >8302 * AMSCRU DATA >8302 * First address. DATA >C04C * MOV R12,R1 * Save R12 DATA >020C * LI R12,>1E00 * Load CRU bits DATA >1E00 * DATA >1D00 * SBO 0 * Set bits ones DATA >C301 * MOV R1,R12 * Restore R12 DATA >04E0 * CLR @>837C * Clear for GPL DATA >837C * DATA >045B * RT * Return to GPL. * END *********************************************************** * CPU PROGRAM FOR >8300 SCRATCH PAD CPU ISR HOOK ON * *********************************************************** * * AORG >8300 GISRON DATA >8302 * DATA >8302 DATA >C820 * MOV @>834A,@>83C4 DATA >834A * DATA >83C4 * DATA >04E0 * EXIT CLR @>837C DATA >837C * DATA >045B * RT * * END *********************************************************** * CPU PROGRAM FOR >8300 SCRATCH PAD CPU ISR HOOK OFF * *********************************************************** GISROF DATA >8302 * DATA >8302 DATA >C820 * ISROFF MOV @>83C4,@>83C4 DATA >83C4 * DATA >83C4 * DATA >1305 * JEQ NHOOK DATA >C820 * MOV @>83C4,@>834A DATA >83C4 * DATA >834A * DATA >04E0 * NHOOK CLR @>83C4 DATA >83C4 * DATA >04E0 * CLR @>837C DATA >837C * DATA >045B * RT * * END *********************************************************** * CPU PROGRAM FOR >8300 SCATCH PAD SUBROUTINE EXECUTE * *********************************************************** * AORG >8300 * CPUPGM DATA >8302 * CPUPGM DATA >8302 First address. * DATA >0420 * BLWP @>834A Switch contex * DATA >834A * FAC not used * DATA >04E0 * CLR @>837C Clear for GPL * DATA >837C * * DATA >045B * RT Return to GPL. * * END * ******************************************************* These all reside at >8300 up to >839B in scratchpad that way they work even without a 32K, but only the case for CALL EXECUTE and CALL ISRON or CALL ISROFF. Quote Share this post Link to post Share on other sites
+RXB #1157 Posted January 3 Ok so first I have installed into start up of RXB 2021 this: *********************************************************** * RXB PATCH FOR GAZOO HARDWARE CART TO SET ROMS *********************************************************** MENU DCLR @>6000 SET ROM BANKS FOR GAZZO CART DST VRAMVS,@>836E Set VDP STACK DEFAULT DST VRAMVS,@>8324 Set VDP STACK DEFAULT DST VRAMVS,[email protected] Set VDP STACK DEFAULT * RXB PATCH CODE FOR PMEMORY UPPER 24K DST CPUBAS,[email protected] Set XB RAM END ADDRESS DST >FFE7,@RAMTOP Set XB RAM START ADDRESS *********************************************************** * INITILIZE SAMS FOR 4MEG CARDS *********************************************************** CALL AMSON DST >5FFE,@FAC Start SAMS Register ST >0F,@FAC2 Value to load AINITL MOVE 1,@FAC2,@0(@FAC) Load value in Register DDECT @FAC Register address-2 DEC @FAC2 Value-1 BR AINITL No, loop CALL AMSOFF CALL AMSMAP BR TOPLEV Restart but below CLR bytes *********************************************************** This should fix the issue with 4Meg or smaller cards. Next I fixed the loader of SAMS with this: CALL MAPAMS * AMS MAP CALL ONAMS * AMS ON * TEMP has RAM address >A000 up to >F000 * Shift address to be 2* value for SAMS register * i.e. >F0 would be >1E so >401E would be register SRL 3,@TEMP * MOVE TO LOWER NIBBLE EX @TEMP,@TEMP+1 * SWAP BYTES EX @FAC1,@FAC * SWAP BYTES ST @FAC1,@>4001(@TEMP) * SET BANK ST @FAC,@>4000(@TEMP) * SET PAGE CALL OFFAMS * AMS OFF I load the ODD BYTE first then the Even byte. That should fix this issues entirely and no need for CALL AMSINIT anymore as it is done each time you start the RXB 2021 Module fresh restart. 1 1 Quote Share this post Link to post Share on other sites
+Ksarul #1158 Posted January 4 Thanks, Rich. Once all is stable for a while, I'll have to make an UberGROM image for the new RXB. . .and some of the cartridges too 3 Quote Share this post Link to post Share on other sites
+wolhess #1159 Posted January 4 17 hours ago, Ksarul said: Though it is "technically" possible to upgrade the older 1M boards, it requires some significant board surgery and isn't generally advisable for those with limited soldering skills. Hi @Ksarul is there a description for changing my SAMS card from 1MB to 4MB capability? It is a revision 4A Board, see post #1147. Wolfgang 1 Quote Share this post Link to post Share on other sites
Vorticon #1160 Posted January 4 9 hours ago, Ksarul said: Thanks, Rich. Once all is stable for a while, I'll have to make an UberGROM image for the new RXB. . .and some of the cartridges too Yes please. 1 Quote Share this post Link to post Share on other sites
+Ksarul #1161 Posted January 4 2 hours ago, wolhess said: Hi @Ksarul is there a description for changing my SAMS card from 1MB to 4MB capability? It is a revision 4A Board, see post #1147. Wolfgang I have not yet written down (or tested) all of the necessary changes to the revision 4A boards. I know it will require several trace cuts, some of which would require removal and replacement of existing chip sockets to get access to the cut points. It would also require two pairs of chips to be stacked (and a lot of flying wires) to add the necessary bits to the selection circuitry. 1 1 Quote Share this post Link to post Share on other sites
+wolhess #1162 Posted January 4 9 hours ago, Ksarul said: I have not yet written down (or tested) all of the necessary changes to the revision 4A boards. I know it will require several trace cuts, some of which would require removal and replacement of existing chip sockets to get access to the cut points. It would also require two pairs of chips to be stacked (and a lot of flying wires) to add the necessary bits to the selection circuitry. Ok, I think I don't want to do that. Nevertheless, thank you very much for the answer Quote Share this post Link to post Share on other sites
+arcadeshopper #1163 Posted January 4 16 minutes ago, wolhess said: Ok, I think I don't want to do that. Nevertheless, thank you very much for the answer you will also gain no benefit other than having ram that's not used.. nothing uses more than 1mb.. and only two things seems to use all of that Quote Share this post Link to post Share on other sites
+TheBF #1164 Posted January 5 3 hours ago, arcadeshopper said: you will also gain no benefit other than having ram that's not used.. nothing uses more than 1mb.. and only two things seems to use all of that Maybe it's just me but I find it starts to get weird with such a slow processor and all that memory. For example, I am sure it could be a bit faster (2x?) in all Assembler, but using two Assembler routines, one to select the page and one to fill a 4K page, it takes 20 seconds to fill the upper 239 pages of the 255 pages using a Forth loop. That is a best case. Times go up when you have actually load something real. However if you just swap in a multiple blocks of pre-loaded pages with a short ASM routine, it is pretty fast so maybe that's the secret of how to use it. I am still playing. (Damn.. Now I gotta try this in machine Forth) 4 Quote Share this post Link to post Share on other sites
+RXB #1165 Posted January 5 6 hours ago, TheBF said: Maybe it's just me but I find it starts to get weird with such a slow processor and all that memory. For example, I am sure it could be a bit faster (2x?) in all Assembler, but using two Assembler routines, one to select the page and one to fill a 4K page, it takes 20 seconds to fill the upper 239 pages of the 255 pages using a Forth loop. That is a best case. Times go up when you have actually load something real. However if you just swap in a multiple blocks of pre-loaded pages with a short ASM routine, it is pretty fast so maybe that's the secret of how to use it. I am still playing. (Damn.. Now I gotta try this in machine Forth) Yea if you use SCSI or IDE or RAMDISK or TIPI it is pretty fast: RXB 2018 CALL SAMS DEMO - YouTube SAMSDEMO1 RXB 2018 - YouTube As you can see here RAM is fast even in XB! 2 2 Quote Share this post Link to post Share on other sites
+RXB #1166 Posted January 21 UPDATE: RXB 2020C is in works and turns out NOTHING IS WRONG WITH RXB using SAMS except SIZE does not report PAGES correctly. The SAMS is INITIALIZED by RXB 2020C but I am having a issue of reading SAMS pages due to REAL IRON vs Classic99. The 1Meg SAMS just refuses Pages to be read correctly as it duplicates PAGES to the BANKS even though THERE ARE NO BANKS! This does not happen in Classic99 of the 1Meg SAMS, but on REAL IRON it does do this HARDWARE BUG! Has taken days to try and get around this issue. Quote Share this post Link to post Share on other sites
+TheBF #1167 Posted January 22 If I understood Tursi correctly, Classic99 behaves like it has a 32M (?) card and so it uses both bytes to reference all that memory. The 1Mb card decoder needs the bytes duplicated for initializing. I have found once that is done, you can get at the memory pages with just putting one byte in the low order byte of the register. Don't know why. Don't really need to know why at this stage. But I get memory pages when I ask for them. 1 Quote Share this post Link to post Share on other sites
Tursi #1168 Posted January 22 Make sure you are initializing /all/ SAMS registers before you start to use the card - if you just go as you need them, then you are relying on the Classic99 initialization, which is going to be different on different hardware. 1 Quote Share this post Link to post Share on other sites
+RXB #1169 Posted January 22 7 hours ago, TheBF said: If I understood Tursi correctly, Classic99 behaves like it has a 32M (?) card and so it uses both bytes to reference all that memory. The 1Mb card decoder needs the bytes duplicated for initializing. I have found once that is done, you can get at the memory pages with just putting one byte in the low order byte of the register. Don't know why. Don't really need to know why at this stage. But I get memory pages when I ask for them. Yes 32Meg and no issues with SAMS in Classic99, plus no need to initialize Registers. Real Iron is a mess at best. Never had a problem with REAL IRON switching pages just the stupid mess made by having to Initialize Hardware Registers. RXB 2001 worked fine with AMS and SAMS later, but to have more then 1Meg it required to bank switch pages of 1Meg up to 256 Banks or 1Meg. It would make sense to allow for this in the original design, they did not. i.e. (high byte) BANKS:PAGES (low byte) But the stupid original AMS put the byte in high and low byte, just a badly thought out design. Quote Share this post Link to post Share on other sites
+RXB #1170 Posted January 22 4 hours ago, Tursi said: Make sure you are initializing /all/ SAMS registers before you start to use the card - if you just go as you need them, then you are relying on the Classic99 initialization, which is going to be different on different hardware. It is a very odd quirk of REAL IRON to put the high byte in low byte also, so I have to make a special routing for 1Meg SAMS. And another for any SAMS larger then 1Meg. This is rather aggravating to have to do the same device. Quote Share this post Link to post Share on other sites
Tursi #1171 Posted January 23 On 1/22/2021 at 1:30 AM, RXB said: It is a very odd quirk of REAL IRON to put the high byte in low byte also, so I have to make a special routing for 1Meg SAMS. And another for any SAMS larger then 1Meg. This is rather aggravating to have to do the same device. Unfortunately I don't have real iron AMS to inspect, I suspect the reason has more to do with compatibility across the various TI systems than the hardware checking both bytes (ie: TI and Geneve write the two bytes in different orders). Classic99 is based largely on convention. But to that end I wonder - if you didn't double up the bytes but did a SWPB before writing, would real hardware suddenly start working? It's probably not the best idea since, if my theory was true, it would not work on a Geneve anymore, but I'm very curious. (And if I'm way off base and it's not a MOV being used, then just ignore me... ) 1 Quote Share this post Link to post Share on other sites
+Ksarul #1172 Posted January 23 On 1/22/2021 at 3:27 AM, RXB said: Yes 32Meg and no issues with SAMS in Classic99, plus no need to initialize Registers. Real Iron is a mess at best. Never had a problem with REAL IRON switching pages just the stupid mess made by having to Initialize Hardware Registers. RXB 2001 worked fine with AMS and SAMS later, but to have more then 1Meg it required to bank switch pages of 1Meg up to 256 Banks or 1Meg. It would make sense to allow for this in the original design, they did not. i.e. (high byte) BANKS:PAGES (low byte) But the stupid original AMS put the byte in high and low byte, just a badly thought out design. Rich, this has nothing to do with a stupidly thought out design. It is a physical limitation of the bank switching chip. The original AMS and SAMS cards only used one byte of the 12-bit address space, making the four high-order bits invisible to programs and the users. In order to get the results they needed, they had to write the address byte twice to ensure that the address they wanted was populating the registers. The first write was shifted to the high-order register when the low order byte was written in--but it had no function as there were no outputs tied to the four high-order bits. This is a requirement of the 74LS612, as it MUST have both bytes written to it for it to work. The original design reflected this limitation of the hardware--it is definitely NOT a bug, it is a feature that programmers have to wrap their minds around to get the card to respond properly. Expansion to 4M uses two of those high-order bits, and expansion to 16M would use all four, so that high-order byte now actually DOES something when it is shifted into the registers. Tursi's variant actually uses one additional high-order bit that isn't available on the 74LS612 to expand the space to 32M. Rich, I have a thought: when writing to set the registers on a 1M SAMS, if you write zeroes in the first byte sent (the high-order byte), it should not try to switch you to bizarro pages that don't exist, as now there won't be spurious ones in the high-order byte. Same goes for the high-order byte in largr cards, always make sure unused bits are set to zero in the first byte sent to set the registers. Following this convention at all times should allow just a single SAMS management routine (set up a variable that identifies card size and mask all necessary initial bits to zero, which will also eliminate potential issues with cards smaller than 1M too). I am really glad you are working to integrate large SAMS support into RXB, as it opens a lot of possibilities for the user community. Thank you! 5 1 Quote Share this post Link to post Share on other sites
+RXB #1173 Posted January 23 5 hours ago, Tursi said: Unfortunately I don't have real iron AMS to inspect, I suspect the reason has more to do with compatibility across the various TI systems than the hardware checking both bytes (ie: TI and Geneve write the two bytes in different orders). Classic99 is based largely on convention. But to that end I wonder - if you didn't double up the bytes but did a SWPB before writing, would real hardware suddenly start working? It's probably not the best idea since, if my theory was true, it would not work on a Geneve anymore, but I'm very curious. (And if I'm way off base and it's not a MOV being used, then just ignore me... ) I assume it just a oddball quirk of the hardware as the older cards do not use the same chips. i.e. old cards 1Meg max vs new cards over 4Meg max. I have a new SIZE routine that forced me to do this: *********************************************************** * SAMS REGISTERS SR2P EQU >4004 SAMS REGISTER PAGE SR2B EQU >4005 SAMS REGISTER BANK SR3P EQU >4006 SAMS REGISTER PAGE SR3B EQU >4007 SAMS REGISTER BANK SRAP EQU >4014 SAMS REGISTER PAGE SRAB EQU >4015 SAMS REGISTER BANK SRBP EQU >4016 SAMS REGISTER PAGE SRBB EQU >4017 SAMS REGISTER BANK SRCP EQU >4018 SAMS REGISTER PAGE SRCB EQU >4019 SAMS REGISTER BANK SRDP EQU >401A SAMS REGISTER PAGE SRDB EQU >401B SAMS REGISTER BANK SREP EQU >401C SAMS REGISTER PAGE SREB EQU >401D SAMS REGISTER BANK SRFP EQU >401E SAMS REGISTER PAGE SRFB EQU >401F SAMS REGISTER BANK *********************************************************** * * SHOW SAMS PAGES & BANKS USED * SAMSZ CALL ISROFF * TURN OFF ISR HOOK CALL AMSMAP * TURN ON MAPPER CALL AMSON * TURN ON WRITE REGISTERS CLR [email protected]>03D0 * Clear buffer MOVE 32,[email protected]>03D0,[email protected]>03D1 * ripple it * Check if larger then 1 Meg SAMS DST @SRCP,@PAD * Save PAGE:BANK >C000 for use ST 2,@SRCB * Set 2 BANK to >C000 DCEQ >0202,@SRCP * 1MEG SAMS? BR MEGUP * No, above 1Meg DST @PAD,@SRCP * Restore PAGE:BANK >C000 * 1Meg or less ST @SR2P,[email protected]>03D1 * >2000 PAGE ST @SR3P,[email protected]>03D3 * >3000 PAGE ST @SRAP,[email protected]>03D5 * >A000 PAGE ST @SRBP,[email protected]>03D7 * >B000 PAGE ST @SRCP,[email protected]>03D9 * >C000 PAGE ST @SRDP,[email protected]>03DB * >D000 PAGE ST @SREP,[email protected]>03DD * >E000 PAGE ST @SRFP,[email protected]>03DF * >F000 PAGE BR DISAMS * 2 Meg or more MEGUP DST @PAD,@SRCP * Restore PAGE:BANK >C000 ST @SR2P,[email protected]>03D1 * >2000 PAGE ST @SR2B,[email protected]>03D0 * >2000 BANK ST @SR3P,[email protected]>03D3 * >3000 PAGE ST @SR3B,[email protected]>03D2 * >3000 BANK ST @SRAP,[email protected]>03D5 * >A000 PAGE ST @SRAB,V@>03D4 * >A000 BANK ST @SRBP,[email protected]>03D7 * >B000 PAGE ST @SRBB,[email protected]>03D6 * >B000 BANK ST @SRCP,[email protected]>03D9 * >C000 PAGE ST @SRCB,[email protected]>03D8 * >C000 BANK ST @SRDP,[email protected]>03DB * >D000 PAGE ST @SRDB,[email protected]>03DA * >D000 BANK ST @SREP,[email protected]>03DD * >E000 PAGE ST @SREB,[email protected]>03DC * >E000 BANK ST @SRFP,[email protected]>03DF * >F000 PAGE ST @SRFB,[email protected]>03DE * >F000 BANK * Display pages and banks DISAMS DCLR @PAD * INDEX POINTER DISPLAY SAMREG XML SCROLL * SCROLL SCREEN DST [email protected]>03D0(@PAD),@ARG2 * REGISTER WORD CALL SDISO * SHOW IT DINCT @PAD * POINTER+2 DCEQ 16,@PAD * DONE? BR SAMREG * LOOP ************************************* * FOR SAMS SIZE SPAGES FMT SCRO >60 ROW 15 COL 4 HTEX '* PAGE NUMBER = LOCATION *' ROW+ 1 COL 10 HTEX 'Page = >2000 - >2FFF' ROW+ 1 COL 10 HTEX 'Page = >3000 - >3FFF' ROW+ 1 COL 10 HTEX 'Page = >A000 - >AFFF' ROW+ 1 COL 10 HTEX 'Page = >B000 - >BFFF' ROW+ 1 COL 10 HTEX 'Page = >C000 - >CFFF' ROW+ 1 COL 10 HTEX 'Page = >D000 - >DFFF' ROW+ 1 COL 10 HTEX 'Page = >E000 - >EFFF' ROW+ 1 COL 10 HTEX 'Page = >F000 - >FFFF' FEND * NOAMS DCZ @FAC * ISR? BS NOISR * No CALL ISRON * Turn on ISR HOOK NOISR CALL AMSOFF * TURN OFF DSR * Quote Share this post Link to post Share on other sites
mizapf #1174 Posted January 23 I wonder why they built the databus multiplexer in the console this way, low-before-high. Not only the 9995 does high-before-low, also the 9980A. So it seems it is the TI-99/4A console that deviates from the order. 2 Quote Share this post Link to post Share on other sites
+RXB #1175 Posted January 23 29 minutes ago, Ksarul said: Rich, this has nothing to do with a stupidly thought out design. It is a physical limitation of the bank switching chip. The original AMS and SAMS cards only used one byte of the 12-bit address space, making the four high-order bits invisible to programs and the users. In order to get the results they needed, they had to write the address byte twice to ensure that the address they wanted was populating the registers. The first write was shifted to the high-order register when the low order byte was written in--but it had no function as there were no outputs tied to the four high-order bits. This is a requirement of the 74LS612, as it MUST have both bytes written to it for it to work. The original design reflected this limitation of the hardware--it is definitely NOT a bug, it is a feature that programmers have to wrap their minds around to get the card to respond properly. Expansion to 4M uses two of those high-order bits, and expansion to 16M would use all four, so that high-order byte now actually DOES something when it is shifted into the registers. Tursi's variant actually uses one additional high-order bit that isn't available on the 74LS612 to expand the space to 32M. Rich, I have a thought: when writing to set the registers on a 1M SAMS, if you write zeroes in the first byte sent (the high-order byte), it should not try to switch you to bizarro pages that don't exist, as now there won't be spurious ones in the high-order byte. Same goes for the high-order byte in largr cards, always make sure unused bits are set to zero in the first byte sent to set the registers. Following this convention at all times should allow just a single SAMS management routine (set up a variable that identifies card size and mask all necessary initial bits to zero, which will also eliminate potential issues with cards smaller than 1M too). I am really glad you are working to integrate large SAMS support into RXB, as it opens a lot of possibilities for the user community. Thank you! Yea I was using GPL DST command and found it crashed the older AMS cards, so I moved to ST as it worked fine with Classic99 and older AMS cards. What is really odd is the page and bank switch did not need to be changed, just the SIZE command. This is what frosts my balls. I now assume it is GPL only works with BYTES even if you use DST (word) instead of ST (byte) thus it writes a single byte each time like MOVE does. OMG I hope the real hardware 4Meg and up cards do not need a whole new rewrite again! Quote Share this post Link to post Share on other sites
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord