Trans D-Bug Express 1.05

[Grazey / PHF]

Head over to http://d-bug.me/ to download the latest version of Trans D-Bug Express (released this week). The #1 disk imager.
New features include - improved speed (fastest MSA reader on the ST), Drive B support, compatible with ST, STe, Mega STe, TT and Falcon, uses low level FDC code (no BIOS routines!), allows BPB to be skipped. More info in the readme contained in the zip file.

[arf]

Nice stuff, thanks! Need to try it.

Deriving from the docs, it doesn’t do ED or HD? (“11x512x83x2 cache” would indicate for me "maximum HyperFormat disk size")

[Grazey / PHF]

Would be easy to change it

Though not sure if MSA supports HD?

Grz

[arf]

Would be easy to change it

Though not sure if MSA supports HD?

I never really used MSA, I used TeleDisk and the like – or FCopy Pro.

[dhedberg]

Looks good! Great work! Will have a look!

[Eero Tamminen]

When emulating MegaSTE with Hatari Git version (which added better emulation for MegaSTE floppy disks), this freezes at startup with black screen.

It's stuck here:

Code: Select all

> profile on
> continue
...
> profile addresses 
# disassembly with profile data: <instructions percentage>% (<sum of instructions>, <sum of cycles>, <sum of i-cache misses>, <sum of d-cache hits>)
$0001fdb6 :             cmpi.w    #$7ff,$ffff8924.w         50.00% (33401928, 534430848, 0, 0)
$0001fdbc :             beq.s     $1fdb6                    50.00% (33401930, 400823148, 0, 0)
Disassembled 2 (of active 2) CPU addresses.

(MegaSTE happened to be first machine type I tried, with all the others it starts up fine.)

[czietz]

When emulating MegaSTE with Hatari Git version (which added better emulation for MegaSTE floppy disks), this freezes at startup with black screen.

I can't test right now on a real MegaSTE, but you should consider the possibility that this is a Hatari issue. (Or even a regression? I didn't test older Hatari versions.) The surrounding code looks ok: it sets the Microwire mask register to $7FF, writes a word to the Microwire data register, then waits until shifting of the data has begun, i.e. until the mask register changes. For some reason this never seems to happen on the Hatari-emulated MegaSTE.

[Grazey / PHF]

Very strange as TDE was developed on an MSTE!

GGN also tested it on his greek MSTE.

Plus if it's Microwire then this relates to the setup code in the maxYMiser driver.

Can you test some other maxy DMA SNDH's ?

I'll do some tracing later today, but suspect it's an Hatari issue.

Grazey

[npomarede]

Just tested under Hatari devel version (same as Eero I guess) and I don't see any problem, music starts OK in megaste mode (tested with tos 2.06fr or emutos 1.0, although given the code to read ff8924 I don't see why it would depend on tos version)

EDIT : just to be more precise, Hatari is handling the "perpetual" shifting of the microwire mask since quite some years, as this is required in several demos or music players. So I suspect a configuration error in Eero's test (or a weird setup)

Nicolas

[czietz]

Sorry, my previous posting was unclear: I can reproduce it under Hatari built from current Git sources: TDE hangs at the same location as Eero reported. I've now found that the issue only happens when I emulate the MegaSTE at 16 MHz. I also tested on a real MegaSTE, where TDE runs irrespective of the CPU clock setting. Therefore, it's still looking much like a Hatari bug, sorry.

Please find my Hatari config attached.

[Eero Tamminen]

I can reproduce it under Hatari built from current Git sources: TDE hangs at the same location as Eero reported. I've now found that the issue only happens when I emulate the MegaSTE at 16 MHz. I also tested on a real MegaSTE, where TDE runs irrespective of the CPU clock setting. Therefore, it's still looking much like a Hatari bug, sorry.

Yes, I can reproduce it happening only at 16Mhz. It doesn't happen with MegaSTE emulation at 8Mhz or at 32Mhz.

When specifying 16Mhz clock (--cpuclock 16), it happens also with STE and TT emulation, but not with ST, MegaST or Falcon emulation.

I.e. it's not actually MegaSTE specific, but CPU clock and STE HW specific.

None of the --cpu-exact/--compatible/--timer-d options affected it, so the issue isn't affected by small variations in cycle counts.

[npomarede]

Sorry, my previous posting was unclear: I can reproduce it under Hatari built from current Git sources: TDE hangs at the same location as Eero reported. I've now found that the issue only happens when I emulate the MegaSTE at 16 MHz. I also tested on a real MegaSTE, where TDE runs irrespective of the CPU clock setting. Therefore, it's still looking much like a Hatari bug, sorry.

Please find my Hatari config attached.

I can see the bug too, it should be easy to fix. I had different results at start because I noticed after that if I start hatari with default ST mode then change tos+megaste mode while hatari is runinng, then megaste mode will run at 8MHz (no microwire bug). But if hatari is started with --machine megaste then it will run at 16Mhz and shows the bug. Something needs to be fixed here to be consistant in Hatari.

As you have a megaste, can you confirm if at boot it will run at 16 or 8 Mhz at the hardware level (before TOS changes anything) ? I had the feeling that at boot the small cache was disabled and cpu was 8 MHz, but I have no machine to check this.

Nicolas

[czietz]

As you have a megaste, can you confirm if at boot it will run at 16 or 8 Mhz at the hardware level (before TOS changes anything) ? I had the feeling that at boot the small cache was disabled and cpu was 8 MHz, but I have no machine to check this.

Yes, the Mega STE starts at 8 MHz and with cache disabled. Not even TOS changes anything about that. For compatibility reasons, I guess? It's up to the control panel ACC (or other additional software) to switch the clock to 16 MHz or to enable the cache.

[npomarede]

Microwire shifting issue should now be fixed in Hatari devel version ; megaSTE mode will also start at 8 MHz like on real HW too.

Nicolas