Glass Z80 assembler | MSX Resource Center (Page 9/21)

Enlighted (6935)

29-10-2018, 08:44

IIRC in r800 the instruction
out (c),0
puts something on port C, but it can be not zero
It should be a current value from some cpu bus, I cannot recollect...
Anyway nothing you can relay on

By sd_snatcher

Prophet (3659)

29-10-2018, 16:47

santiontanon wrote:

(and yeah, I'm cutting it so short, I'm using up to the very last byte of addressable memory in one of my current projects, hahaha)

Humm. Is is for an MSX software? If that's the case, Probably it will help if I remind you that this address is not memory on the MSX standard. The subslot register is located there.

Other architectures like the SMS also reserve this address for special purposes.

By santiontanon

Paragon (1805)

30-10-2018, 05:00

I'm coding two games at the moment (one for MSX and one for Amstrad CPC), and I use Glass for compiling both. The issue arose on the Amstrad one (that address is part of the memory-mapped video memory and is accessible). But you are probably right that this is not an issue on MSX

By TomH

Champion (361)

31-10-2018, 15:08

sd_snatcher wrote:

santiontanon wrote:

(and yeah, I'm cutting it so short, I'm using up to the very last byte of addressable memory in one of my current projects, hahaha)

Humm. Is is for an MSX software? If that's the case, Probably it will help if I remind you that this address is not memory on the MSX standard. The subslot register is located there.

Is this strictly, pedantically true? My reading of the Red Book is that $FFFF can be used for a secondary slot register, but can be just regular RAM or ROM, and the BIOS will test to find out whether $FFFF is just plain old memory.

By Grauw

Ascended (10768)

31-10-2018, 22:15

Correct, there are fields in the system are that indicate whether a slot is expanded. The logic whether FFFFH is a register is in the slotexpander, so whether writes and reads to this address are intercepted depends on the presence of it. (Writes do not arrive at the underlying RAM either.)

By sd_snatcher

Prophet (3659)

01-11-2018, 01:45

TomH wrote:

Is this strictly, pedantically true? My reading of the Red Book is that $FFFF can be used for a secondary slot register, but can be just regular RAM or ROM, and the BIOS will test to find out whether $FFFF is just plain old memory.

Oh my. That "pedantically" part of your question was quite rude. But the rest of the sentence can be considered theoretically true. I just did a simple explanation without going the trouble to explain everything into (what could be considered) "pedantic details" of how unpractical it would be. What was important was to give advice to a fellow developer that this address cannot be used as ordinary RAM without risks.

Because:

1) Ordinary RAM wouldn't require any special protocol to know if each byte is special or not

2) It's a lot of hassle for a measly byte. You'll certainly waste way more bytes with code to detect if that byte is free and to use it. And quite a bit of CPU time. Worst yet if you consider that you'll have to provide an alternative for when the code runs on a machine with expanded slots. It will probably be faster and less risky to read/write bytes on the VRAM if the situation for memory is so desperate. Many MSX games go that way.

By TomH

Champion (361)

01-11-2018, 02:38

sd_snatcher wrote:

TomH wrote:

Is this strictly, pedantically true?...

Oh my. That "pedantically" part of your question was quite rude.

No it isn't. It acknowledges that I'm a pedant for asking, i.e. that I'm not disputing that what you said is 99% true, and the thing worth remembering if you remember anything, but I'm just wondering about the 1%.

By Grauw

Ascended (10768)

12-01-2020, 15:49

I fixed a bug where includes didn’t resolve when the source file’s path had no directory prefix. Thanks to Maarten Loor for reporting.

Additionally I’ve made it so that labels always associate themselves with the next statement, rather than only the line they are on. With this you no longer need to put the statement on the same line if you want to access the macro symbols inside with the . operator. The symbol file output is also improved by this.

Get the latest development build here: http://www.grauw.nl/etc/msx/glass.jar

By thegeps

Paragon (1187)

12-01-2020, 18:06

Thanks for your work!

By Wlcracks

Hero (565)

12-01-2020, 18:13

Cool thanks.