Hi,
the documentation states:
reload dest_addr source_addr len [filename]
|
But if I read this from another cartridge, only 0 bytes are read into the current memory. Is this part of the documentation outdated or am I doing something wrong? Code would be simply:
reload(1024,0x4300,10,"tor_carttest.p8") peek(1024) |
while there is an empty function inside of the other cartridge...
I wrote a simple program to show the issue:
cls() reload(0x1000,0x4300,128) for i=0,128 do print(peek(0x1000+i),(i%8)*16,flr(i/8)*8,6) end |
Which SHOULD print out the character codes of itself, believing the documentation. Instead, every byte is zero. So, my question again - is the documentation outdated here and this feature has been removed or is this a bug?
Hi SunSailor
This is indeed outdated documentation -- corrected for 0.1.6. The early alpha versions stored code as plain ascii in the code section, but is now compressed to allow more code to be stored in the same 0x3d00 byte block, due to token counting being introduced. I don't think there is a meaningful way to read/write data straight out of the code section, and the whole separate Lua code thing is necessarily awkward in the first place, so it's not something I want to expose. It's still possible to stuff extra data in code though (albeit less efficiently), using long strings with SUB().
With one cartridge you would be right, but I need to use two cartridges minimum anyway and there it would have been cool to be able to place a string table or extra graphics in the this way unused code segment. Anyway, I can work around this by using a third cartridge, but it feels a bit unsatisfying that I need to do that, while the second cartridge is virtualy still half empty.
Still, it would be great to have that space available again, naturally uncompressed. There is plenty of address room between the screen memory and the 64k limit of 8bit computers, so mapping the text data of the source code section uncompressed there would be a great win, although I still think, bigger cartridges with a mapping approach would be the perfect solution. I use this technique in Nano89 very successfully, where the base system has a 64k limit, but the cartridges can be up to 1mb, accessed in 256x4kb banks mapped into $f000-$ffff.
[Please log in to post a comment]