Log In  

Hi,
the documentation states:


reload dest_addr source_addr len [filename]

Same as memcpy, but copies from cart rom
if source_addr >= 0x4300, can read code ascii into ram
if filename specified, load data from a different cartridge


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...

P#19351 2016-03-21 18:43 ( Edited 2016-03-23 20:23)

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?

P#19373 2016-03-23 04:56 ( Edited 2016-03-23 09:51)

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().

P#19376 2016-03-23 15:57 ( Edited 2016-03-23 19:57)

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.

P#19377 2016-03-23 16:23 ( Edited 2016-03-23 20:29)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 23:03:16 | 0.006s | Q:11