Glass Z80 assembler

Pagina 9/13
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12 | 13

Van ARTRAG

Enlighted (6333)

afbeelding van ARTRAG

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

Van sd_snatcher

Prophet (3244)

afbeelding van sd_snatcher

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.

Van santiontanon

Paladin (872)

afbeelding van santiontanon

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 Smile

Van TomH

Champion (327)

afbeelding van TomH

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.

Van Grauw

Ascended (8735)

afbeelding van Grauw

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

Van sd_snatcher

Prophet (3244)

afbeelding van sd_snatcher

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.

Van TomH

Champion (327)

afbeelding van TomH

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

Van Grauw

Ascended (8735)

afbeelding van Grauw

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

Van thegeps

Champion (370)

afbeelding van thegeps

12-01-2020, 18:06

Thanks for your work!

Van Wlcracks

Champion (409)

afbeelding van Wlcracks

12-01-2020, 18:13

Cool thanks.

Pagina 9/13
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12 | 13