Device NOSLOT64K and Paging

[S0urceror]

Description I am currently implementing a ZDI debugger for the AgonLight based on your codebase. I created a remote called the AgonElectronHALremote that is derived from RemoteBase.

The Agon has 512Kb of RAM and an EZ80 processor. In Z80 mode an address is comprised of the MBASE + 64Kb address. I use the NOSLOT64K device and paging in sjasmplus to tell the compiler we are running at for example page/mbase 5.

When I set a breakpoint however, I noticed that Dezog always returns page 0 for every address which is in the ROM kernel page of the Agon Light and not in the RAM space.

To Reproduce

    DEVICE NOSLOT64K
    PAGE 5
CHPUT equ 00a2h

; BLOAD header
    db 0x0fe
    dw BEGIN, ENDADR, START_BASIC

    org 9000h
BEGIN:
START_BASIC:  
    ld hl, strHello
    call print
    DB 049h
    ret

print:
    ld a,(hl)
    and a
    ret z
    inc hl
    call CHPUT
    jr print

strHello db "Hello MSX!",13,10,0

ENDADR:

Suggested fix I tracked this issue down to the checkMappingToTargetMemoryModel function in sjamplusldlabelparser.ts.

I had to return bank-1 to have addresses correctly converted to 0x05zzzz.

Version etc. (please complete the following information):

• DeZog SW Version: nightly
• OS: MacOS
• Remote: agonelectronhal (not released yet)

Question Let me know if paging for NOSLOT64K should be implemented like this. If not please let me know what is the best approach here.

[maziac]

Hello S0urceror, It has been some time since you last contributions. Hope everything is fine. Are you still planning to add a openmsx remote?

I have currently no access to my computer. Please give me a few days to answer your questions.

[maziac]

Just a hint for now. I think the main problem is that the destination memory model (the target system) is unknown to dezog. You would need to define a new one.

[S0urceror]

You are right. My approach is wrong. I used MemoryModelAllRAM (dst) with NOSLOT64K (src). Instead I should have introduced a new MemoryModelAgonLight (dst) with its own funcConvertBank to do the mapping.

Thanks for the hint. Closing this issue now.

I'll let you know when I'm done implementing and will share the resulting code with you.

[maziac]

I'm happy to help. Which emulator is this for?

[S0urceror]

It's for the AgonLight (https://www.thebyteattic.com/p/agon.html) which is a miniature computer. There is quite a large following creating software for it.

I made an alternative OS called ElectronOS (https://github.com/S0urceror/AgonElectronOS) for it. Unique for this OS is that it has a debug console that talks to the Zilog ZDI interface. This enables you to do CPU-level debugging.

I want to use Dezog to interface with this via an USB cable so that I can do development from VSCode.

[maziac]

Oh, a HW debug interface. That sounds interesting.

[S0urceror]

I just pushed my AgonLight branch to my Github. You can check it out here: https://github.com/S0urceror/DeZog/tree/agonlight

It's based on your latest build and contains the changes to connect to the HW debugger via USB serial.

[maziac]

I have given a few comments here, especially for the agonelectronhalremote.ts: https://github.com/maziac/DeZog/compare/main...S0urceror:DeZog:agonlight#diff-8d975b246740d20b4908e528c2a4b62ddb2b3fc1a44e049389b3df5ded4fb973R285

Nice piece of work. Looks to me that it could work :-)

It seems that you have used the ZesaruxRemote as base. I wouldn't recommend doing that (and I must make a note in the documentation). The Zesarux was the first Remote I implemented. All other remotes, even the MAME, work much more similar to each other and especially require lower maintenance effort. You can see this with e.g. the MameRemote which is inherited from the DzrpBufferRemote. Using the Dzrp... classes does not mean that you have to implement the DZRP on the transport layer. As you can see for the Game it simply overrides the sendDzrpCmd... functions and sends the gdb commands instead.

The advantage is that you have to implement less by yourself and the debug experience is much more similar between the Remotes. (E.g. the way how step-over or step-out is handled, which can be very debugger specific.) Also the breakpoint conditions are handled for you and it is not necessary to implement debugger specific stuff (as e.g. with zesarux).

Unfortunately I haven't got any AgonLight HW to do/test this by myself, but I could assist you or provide an initial (untested) implementation for you, if you like.

[S0urceror]

Thanks for taking the time to review my work. Greatly appreciated.

When I looked into Dezog since 2020 I noticed the DZRP work. I took it as another abstraction for the DZRP protocol only. But indeed MAME uses gdb format which I kind of loosely followed when I implemented the debug interface for AgonLight. Are you planning to drop RemoteBase and move to DZRP in the future? Because then it's better to reimplement and make things easier.

On the other hand it starts working quite good. I'll make a video soon for the Agon community to show this off.

[maziac]

I have no plan to remove the RemoteBase. On the other hand I had plans to rewrite the ZesaruxRemote to make it work similarly to the DZRP Remotes. This is to lower the maintenance work. I noticed that my efforts for maintaining are doubled because of zesarux or better the different way I had implemented it. I always have to test zesarux and the rest. The rest behaves very similar. Zesarux requires a special implementation. Now if you go that way for AgonLight it would be similar. I.e. I have to implement and test for zesarux, AgonLight and the rest. For me this is not working for 2 reasons: a) it increases the maintenance effort (I would rather go the different way) b) I don't even have the HW to test.

So, please understand: If you stay on the RemoteBase-solution then you can keep your fork, of course, and use it and share it with others. But I would rather not integrate it into the dezog main branch.

[S0urceror]

Okay, I checked DzrpQueuedRemote and it doesn't look very difficult to move my code to there. Thx for the explanation.

Btw. I also think that integrating with the main branch is not the aim here and will stay on a separate fork. The AgonLight is a different thing with an EZ80 instead of a Z80.

Just would like to stay on a parallel lane so that when you introduce new features I would be able to easily bring them over. Then it's good to know what you think is stable and what you will overhaul in the future.

[maziac]

OK. That sounds fine to me.