nextreg access

Do you live and breathe hexadecimal? Do you like speaking to hardware directly?

Moderator: Programming Moderators

User avatar
sol_hsa
Posts: 273
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

nextreg access

Postby sol_hsa » Sun Apr 26, 2020 7:15 am

Why doesn't this work:

Code: Select all

out (#0x243B), a ; nextreg select
in  a,  (#0x253B)  ; nextreg i/o
but this does:

Code: Select all

ld      bc, #0x243B   ; nextreg select
out     (c), a
inc     b       ; nextreg i/o
in      a, (c)   

User avatar
sol_hsa
Posts: 273
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: nextreg access

Postby sol_hsa » Sun Apr 26, 2020 7:54 am

Still not sure if I'm doing things right. I'm trying to mess around with the MMU, so, while interrupts are disabled I read the mmu0, write some value to mmu0, and then restore the original value to mmu0. The system crashes. This is a dot application.

mmu0-7 values read (nextregs 0x50-0x57) at entry:

Code: Select all

254 254 009 010 003 004 000 000
Those values look a bit suspect - the first one should definitely be rom, so I'd expect 255, and the last two are the same which doesn't look right.

dave18
Posts: 186
Joined: Tue May 30, 2017 1:06 am
Location: Bristol, UK

Re: nextreg access

Postby dave18 » Sun Apr 26, 2020 8:38 am

You can't pass a 16 bit value using in a, out a so you have to load it into BC first and then use in c, out c

I think technically in a, out a does present a 16 bit address to the io but I can't remember off hand where the other 8 bits are generated from.

dave18
Posts: 186
Joined: Tue May 30, 2017 1:06 am
Location: Bristol, UK

Re: nextreg access

Postby dave18 » Sun Apr 26, 2020 8:40 am

With the mmu, are you sure you aren't paging out the stack, even with interrupts disabled that will cause a crash if any calls, push or pops are used.

User avatar
sol_hsa
Posts: 273
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: nextreg access

Postby sol_hsa » Sun Apr 26, 2020 8:46 am

I'm only messing with slot 0 which should be rom. The system crashed only after the application is done. This means I managed to break something, but I'm not sure if I broke the right thing ;)
I still think I have something fundamentally wrong given those read values.

Re: 8 bit port address - makes sense, too bad the assembler didn't give a warning.

Ped7g
Posts: 256
Joined: Mon Jul 16, 2018 7:11 pm

Re: nextreg access

Postby Ped7g » Sun Apr 26, 2020 10:31 am

Code: Select all

    out (#0x243B), a ; nextreg select
    in  a,  (#0x253B)  ; nextreg i/o
there's no such instruction on Z80. If I modify this to sjasmplus syntax:

Code: Select all

    out (0x243B), a ; nextreg select
    in  a,  (0x253B)  ; nextreg i/o
it will report:
Main.asm(37): warning: value 0x243B is truncated to 8bit value: 0x3B
Main.asm(38): warning: value 0x253B is truncated to 8bit value: 0x3B

Both `in` and `out` with immediate 8b constant take value in register A as top 8 bits of I/O address, so the only next-register which you can select by `out (0x3B),a` is register 0x24, which is not mapped to any particular functionality (probably intentionally, to avoid something like this triggered by accident by legacy code sending "out" to unexpected ports).

But you can do the IN part:

Code: Select all

    ld a,0x25
    in  a,  (0x3B)  ; read selected nextreg i/o
But the usual way is to use in/out with "(c)", which actually on Z80 means "(bc)", and keep the full port address in BC, then to read NextRegister you can do it like this (my subroutine + macro from the test suite):

Code: Select all

TBBLUE_REGISTER_SELECT_P_243B equ 0x243B
TBBLUE_REGISTER_ACCESS_P_253B equ 0x253B

ReadNextReg:
    ; reads nextreg in A into A (does modify currently selected NextReg on I/O port)
    push    bc
    ld      bc,TBBLUE_REGISTER_SELECT_P_243B
    out     (c),a
    inc     b       ; bc = TBBLUE_REGISTER_ACCESS_P_253B
    in      a,(c)   ; read desired NextReg state
    pop     bc
    ret

; Read NextReg into A (does modify A, and NextReg selected on the I/O port)
; is not optimized for speed + restores BC
    MACRO NEXTREG2A register?
        ld     a,register?
        call   ReadNextReg
    ENDM
About MM0 mapping ... definitely should work, works for me in many tests.
Be aware the somewhat older version of CSpect did report value "0" on read of MMU0 reg instead of "255" (ROM), but for last maybe 10 versions this is fixed already, definitely works in V2.12.22 as it should.

If you can produce some minimal example where it does crash for you, I can check the source code what's the issue.

User avatar
sol_hsa
Posts: 273
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: nextreg access

Postby sol_hsa » Sun Apr 26, 2020 12:33 pm

Ped7g wrote:
Sun Apr 26, 2020 10:31 am
If you can produce some minimal example where it does crash for you, I can check the source code what's the issue.
As you may suspect from the weird assembler syntax, this is a sdcc project. Also explains why the assemlber didn't complain, it has its issues.

While preparing that minimal example for you I found out the stack operations in sdcc work in a slightly different way than I expected, which explains the problems I'm having.

User avatar
sol_hsa
Posts: 273
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: nextreg access

Postby sol_hsa » Sun Apr 26, 2020 12:56 pm

Yup, that seems to have done it.

Also helps to have a number printing routine that actually prints the correct numbers..

Code: Select all

255 255 010 111 004 005 000 001   On entry
002 255 010 111 004 005 000 001   After writing 2 to mmu0 
255 255 010 111 004 005 000 001   After returning original mm0 value
Still weird that the first two banks say they're ROM, when the dot command executes from 2000h

User avatar
SevenFFF
Posts: 565
Joined: Mon Jun 05, 2017 5:30 pm
Location: USA

Re: nextreg access

Postby SevenFFF » Sun Apr 26, 2020 1:01 pm

The first two banks at this point are divMMC RAM, which is paged by a different mechanism and doesn’t have MMU bank numbers.

In this context 255 really means “not an MMU bank”.

Anything in the first 256KB without bank numbers in the global memory map table on this page will report 255:

https://wiki.specnext.dev/Memory_map
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins

User avatar
sol_hsa
Posts: 273
Joined: Fri Jun 02, 2017 10:10 am
Location: Finland
Contact:

Re: nextreg access

Postby sol_hsa » Sun Apr 26, 2020 1:20 pm

Ah, that clarifies things a lot. Thanks.


Who is online

Users browsing this forum: No registered users and 4 guests