Opry99er Posted October 6, 2015 Share Posted October 6, 2015 (edited) I get SYNTAX errors when I try to type this in OR put it at the start of a program. CALL LOAD(-31868,0,0) Hmmm..... ****EDIT***** Forgot CALL INIT first. It's late. Working now. Looks like I have 11,816 BYTES free. Should work just fine for me. Thanks!! Edited October 6, 2015 by Opry99er 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 6, 2015 Share Posted October 6, 2015 Welp... I tried pasting a listing into Classic99 after disabling 32k and it hung after 36 lines... Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 6, 2015 Author Share Posted October 6, 2015 The memory is still there in that case, of course, it's just that you've changed the memory pointers such that XB thinks it's full. It's not quite the same as it being non-present and I can't say for sure that those values are 100% safe (some of the old CALL LOADs floating around only work halfway). Classic99 doesn't have an intrinsic way to disable the 32k memory expansion, but the way that it works is that anything which is not ROM is RAM. Therefore, just create an entry in your Classic99.ini which gives you Extended BASIC /and/ loads ROM in the RAM space. The actual file you load can be anything, the important part is that XB can't write to it, so the memory test will fail and it will determine there is no 32k memory. An entry like this SHOULD work: [usercart1] Name=XB without 32k rom0=o|0000|0004|XB rom1=C|2000|2000|classic99.exe rom2=C|A000|6000|classic99.exe The tricks here are type 'o' which loads an "other" cart - group 0, entry 4, which happens to be Extended BASIC. rom1 and rom2 load the emulator itself as ROMs, selected just because I knew it would exist and be large enough. However, there's a bug in the currently released version of Classic99 where RAM is forced to exist in the 32k space even after it loads the data. I ran into this myself a couple of weeks ago testing XB27 without memory, so I have a fix that needs to be released first. I also have a file system regression to investigate, but work has me on crunch work schedule, so it may be a bit till I can get to it. I'll try again for this weekend. This trick won't work until then. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 6, 2015 Author Share Posted October 6, 2015 I can confirm that CALL LOAD -31868 screws things up really bad -- you can see it yourself by checking size after entering just a couple of lines. That's writing to >8384 which is the TOP of free RAM in the top 24k bank. It's >FFE7 by default. Setting it to zero seems to work against the SIZE command but isn't enough to correctly reinitialize the XB environment. You CAN force it with the debugger, though. XB makes two checks for memory expansion, we can just defeat them both. Start with XB at the READY prompt. Open the debugger and set a breakpoint on writes with ">FFE7", and another with ">DFFF". Type 'NEW' to restart XB. When it breaks the first time, change the value at >FFE7 to zero with the edit box at the bottom of the debugger ("CFFE7=0"). Press F1 to continue. It will break again immediately (so be careful not to double tap). Now set >DFFF to zero with "CDFFF=0". Press F1 to continue. (Interestingly, this suggests that XB was designed to work with a smaller memory expansion -- if you fail the first check but pass the second, XB initializes with 16k Program space free instead of 24k). XB will start and when you do a SIZE you'll see the normal 11840 bytes free -- the difference is XB has set itself up for no memory expansion. This will survive until NEW. (and you can leave the breakpoints in place in case you need to do it again). 4 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 6, 2015 Share Posted October 6, 2015 I have seen references to a 16K memory expansion somewhere or other, I'll have to go digging to see exactly where (it showed up in one of the many system specification documents, IIRC), so what you found out here just confirms that they actually had the hooks in place to implement it, Tursi. I doubt they ever actually "built" them though, as the incremental cost between the 32K sidecar and a downsized 16K device would have been minimal--even with the cost of memory chips back in early 1980. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 7, 2015 Author Share Posted October 7, 2015 Yes, just another interesting legacy left in the code! 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 7, 2015 Author Share Posted October 7, 2015 -Updated TurboForth to 1.2.1:4-Added XB2.7 suite 060315-make Windows text files read only as DV (fixes assembling with EA from TXT files)-Enable disabling 32k by loading ROM overtop of it http://harmlesslion.com/software/classic99 7 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 9, 2015 Share Posted October 9, 2015 DLing now! Thanks for the update, Tursi!!! Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted October 9, 2015 Share Posted October 9, 2015 Hmmm, I've never seen this before... Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 9, 2015 Share Posted October 9, 2015 Start with XB at the READY prompt. Open the debugger and set a breakpoint on writes with ">FFE7", and another with ">DFFF".Type 'NEW' to restart XB. When it breaks the first time, change the value at >FFE7 to zero with the edit box at the bottom of the debugger ("CFFE7=0"). Press F1 to continue. It will break again immediately (so be careful not to double tap). Now set >DFFF to zero with "CDFFF=0". Press F1 to continue. This is precisely what I have done and it works great! I noticed that you indicated you have added additional support for disabling 32k... I did not see anything in the manual on how to do this or any new setting in the ini file or Options submenu. I do not mind doing it manually as you have laid out above, I was just curious if there was a quick option for it now. Nice update. Love having 2.7 on my stock dropdown. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted October 10, 2015 Share Posted October 10, 2015 -Updated TurboForth to 1.2.1:4 -Added XB2.7 suite 060315 -make Windows text files read only as DV (fixes assembling with EA from TXT files) -Enable disabling 32k by loading ROM overtop of it http://harmlesslion.com/software/classic99 TF just went to version 1.2.1:5 ... Willsy is on a roll 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 10, 2015 Author Share Posted October 10, 2015 Hmmm, I've never seen this before... Grr. My fault, I didn't realize the bits were preserved inside an archive. You can safely ignore warnings about losing decryption status. I will be more careful on the next release. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 10, 2015 Author Share Posted October 10, 2015 I noticed that you indicated you have added additional support for disabling 32k... I did not see anything in the manual on how to do this or any new setting in the ini file or Options submenu. I do not mind doing it manually as you have laid out above, I was just curious if there was a quick option for it now. No, I didn't have time to do any new code changes -- the fix was done a few weeks ago. But the fix was just to enable the hack I described above... it was always wrong that it didn't work anyway, you're supposed to be able to load ROM anywhere. (The bug was that it didn't check the rom status before writing in the 32k spaces). Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 10, 2015 Author Share Posted October 10, 2015 (I'm talking about the INI based hack in post 953, that is ) Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 10, 2015 Share Posted October 10, 2015 Thank you for the info, and the update. When DO you come home, BTW? Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 10, 2015 Author Share Posted October 10, 2015 It's not clear yet. When everything's done, I guess. Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted October 10, 2015 Share Posted October 10, 2015 I'm running virtual box on a linux laptop with a windows vm guest... So, due to pressures to provide IT support at home, I let Windows 10 happen to this vm... Classic99 just gives me an empty display... Anyone able to run Classic99 in Windows 10? Any compatibility mode tricks that are known? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 10, 2015 Share Posted October 10, 2015 It works fine for me in Windows 10. I haven't changed anything after upgrading to Windows 10 so I can't help you with any tricks. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 10, 2015 Share Posted October 10, 2015 I'm running virtual box on a linux laptop with a windows vm guest... So, due to pressures to provide IT support at home, I let Windows 10 happen to this vm... Classic99 just gives me an empty display... Anyone able to run Classic99 in Windows 10? Any compatibility mode tricks that are known? Classic99 works on everything i've tried including wine under linux :-) you might need DirectX additional stuff if you have a non upgrade install.. Those of us that came from 7 have that already.. Greg Quote Link to comment Share on other sites More sharing options...
+jedimatt42 Posted October 11, 2015 Share Posted October 11, 2015 ok, my issue was solved by turning off virtual-box 3D acceleration. I may have to give wine a try for grins. Thanks! 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted October 11, 2015 Share Posted October 11, 2015 ok, my issue was solved by turning off virtual-box 3D acceleration. I may have to give wine a try for grins. Thanks! yah virtual-box is problematic.. I'd use vmware player or kde Greg Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 12, 2015 Share Posted October 12, 2015 But, to demonstrate, this INI entry runs Gazoo's XB27 cart. Type 'U' is UberGROM Flash (GROM) data, and type 'T' is the UberGROM EEPROM space. Type '8' is the standard 378-style non-inverted cart ROM. Tursi, does this mean that a file with name [binary]8.bin should load as a ROM-only 378 style cart when loading from the Cartridge -> User menu? Is there a default bank in which these carts start up in Classic99? Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 12, 2015 Author Share Posted October 12, 2015 Tursi, does this mean that a file with name [binary]8.bin should load as a ROM-only 378 style cart when loading from the Cartridge -> User menu? Is there a default bank in which these carts start up in Classic99? Yes, User->load supports '3' for 379 style (inverted) and '8' for 378 style (non-inverted). The highest bank selection is set as the default. (So for inverted ROMs, the first page on the EPROM, for non-inverted the last. Pretty sure on that... that's what the code says but I don't have time to prove it. I also don't guarantee that to never change, since the real hardware doesn't guarantee it, but if it changes it'll at least be an option.) Quote Link to comment Share on other sites More sharing options...
TheMole Posted October 12, 2015 Share Posted October 12, 2015 Yes, User->load supports '3' for 379 style (inverted) and '8' for 378 style (non-inverted). The highest bank selection is set as the default. (So for inverted ROMs, the first page on the EPROM, for non-inverted the last. Pretty sure on that... that's what the code says but I don't have time to prove it. I also don't guarantee that to never change, since the real hardware doesn't guarantee it, but if it changes it'll at least be an option.) Cool, thanks. That explains why alexkidd wouldn't run in classic99, I don't have a header in the last bank (I haven't put headers in the banks that are only padding). That's easy enough to fix. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted October 12, 2015 Share Posted October 12, 2015 A note on 378s. I've tested about 500 of them now and most of them start in either the first or the last bank (I use the ones that hit other start addresses for UberGROM boards), so it is probably a good idea to have your startup code in both of those banks, as that will hit successfully on every cartridge board I build. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.