Hatari 1.8.0 has been released

A forum about the Hatari ST/STE/Falcon emulator - the current version is v2.3.0

Moderators: simonsunnyboy, thothy, Moderator Team

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2512
Joined: Thu Sep 15, 2005 10:01 am
Location: Serbia
Contact:

Re: Hatari 1.8.0 has been released

Post by calimero »

Ok. I see...

Thanks.

And regarding non-displaying gui problem?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

calimero wrote:And regarding non-displaying gui problem?
No idea, it's something OSX build specific, and I don't have a Mac.

PS. The WinUAE CPU core Falcon memory state & restore issue can be worked around by enabling FPU before saving the state.
darwinmac
Captain Atari
Captain Atari
Posts: 303
Joined: Sat Aug 06, 2011 2:49 pm
Location: San Jose, USA

Re: Hatari 1.8.0 has been released

Post by darwinmac »

calimero wrote:Ok. I see...

Thanks.

And regarding non-displaying gui problem?
As Eero said, it is an OS X-specific problem. As it turns out, it is another of the SDL 1 bugs in the OS X port. What is weird is that the non-displaying SDL menu only happened when you were running using the WinUAE CPU option. The SDL menu always appeared for me when using the older UAE CPU support. I just compiled it with the very experimental SDL 2 support and the SDL menu appears (finally!). It also allows you to exit Hatari using the WinUAE CPU without Hatari crashing on exit.

There are some remaining problems in the OS X SDL2 Hatari port so I do not see even a beta version of it being available for a while. Even once the remaining OS X Hatari problems can be resolved, the SDL project needs to release 2.0.4 because a number of the remaining problems are in the SDL library itself (only the OS X port).


Bob C
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2512
Joined: Thu Sep 15, 2005 10:01 am
Location: Serbia
Contact:

Re: Hatari 1.8.0 has been released

Post by calimero »

Thanks for answer!
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

I have some more hard disk emulation issues:
ACSI (without ICD extension) driver, old version, used for work with DOS partitions and BigDOS crashes with double bus error in Hatari 1.8, in early stage, before writing anything on screen. But same image works well in Hatari 1.7 and Steem (with Pasrti) . And of course it works on real HW.
I can post image of it, if will help in resolving problem.

Other is blitter and IDE emulation related, and stays for all Atari versions: in older driver I used blitter for byte-swap, because it is faster than with CPU.

Code: Select all


; BLiTTER base address without halftone

bBLiTTER	equ	$ffff8a20

; BLiTTER register offsets

SRCXINC		equ	$0	; SouRCe X INCrement
SRCYINC		equ	$2	; SouRCe Y INCrement
SRCADDR		equ	$4	; SouRCe ADDRess
ENDMASK1	equ	$8	; ENDMASK 1
ENDMASK2	equ	$a	; ENDMASK 2
ENDMASK3	equ	$c	; ENDMASK 3
DESTXINC	equ	$e	; DESTination X INCrement
DESTYINC	equ	$10	; DESTination Y INCrement
DESTADDR	equ	$12	; DESTination ADDRess
XCNT		equ	$16	; X CouNT
YCNT		equ	$18	; Y CouNT
HOP		equ	$1a	; Halftone OPerations
OP		equ	$1b	; logic OPerations
BUSY		equ	$1c	; register that has the BUSY bit
SKEW		equ	$1d	; SKEW

initblit    * Init blitter to read from IDE if
	lea	bBLiTTER.w,a2	; a2 -> BLiTTER register map
	
    clr.l (a2)+  ; BliTTER Init xInc,yInc source
    move.l #datar,(a2)+ ; Source address
    moveq #255,d0    
    move.l d0,(a2)+ ;
    move.w d0,(a2)+ ;    Endmasks ***
    move.l #$20000,(a2)+ ; xInc,yInc destination
    move.l a0,(a2)+  ;dest addr.
    move.l #$01000001,(a2)+  ;Xcnt, Ycnt
    move.w #$203,(a2)+ ;HOP, OP

....
* d3=sector count-1

  *Blitter ! - transfers 512 bytes:
blitit       
             move.w #$1,YCNT-BUSY(a2)  ; Ycnt  
	move.w	#$c000,(a2)	; start the BLiTTER	
blres	nop
	tas	(a2)	; restart BLiTTER and test if busy
	bmi.s	blres	
	addq.l	#2,DESTADDR-BUSY(a2)

*Load all sectors from d3 loop at once
  
  dbf d3,wrdy


* Sector byte-swap using blitter:
* after reading sector(s) from IDE

  lea	bBLiTTER.w,a2 

* a0 points to block address, d2=sector count-1

  moveq #2,d0
  move.l d0,(a2)+  *X, Y src increment
  move.l a0,(a2)+  *src same as dest
  addq.l #6,a2  *skip mask fields
  move.l d0,(a2)+  *X, Y dest. increment
  move.l a0,(a2)+  *Dest address
	addq.l #6,a2
   *Code from Shrimp originally

blitit2      
        move.l	#$10100,-6(a2)	; 1 to X, 256 to Y 
	move.w	#$c088,(a2)	; start the BLiTTER	
blres2	nop
	tas	(a2)	; restart BLiTTER and test if busy
	bmi.s	blres2	

* for more sectors :
    lea 512(a0),a0  
    move.l a0,-24(a2)  *required 
    move.l a0,-10(a2)  *required 

   dbf d2,blitit2

I need to turn off blitter, otherwise no data in partitions . Partition detection goes without blitter, which activates only in RWABS, for disk read. So, partitions are properly detected, but no data access. What means that code above works not properly in Hatari.
Can supply image, if needed.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

AtariZoll wrote:I can post image of it, if will help in resolving problem.
...
Can supply image, if needed.
Having a test-case will always help.
AtariZoll wrote:I need to turn off blitter, otherwise no data in partitions.
Have you tested both parts in isolation? So that IDE part works without blitter, and blitter side works without IDE, and issue is only with IDE + Blitter combo?
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

AtariZoll wrote:It would be much better and more user friendly if just could set what letter to assign for GEMDOS partition in disk setting menu.
My hard disk driver will not overwrite TOS drives bitmap, but Hddriver overwrites.
It will be than max flexible, and hard disk driver will just create partitions in "free letter slots", in order.
It's better for things to work automatically instead of user needing to configure them.

Hatari already checks how many partitions given ACSI image has and doesn't assign GEMDOS HD drive to something overlapping them, but to a first free drive letter after ASCI partitions. Doesn't that work? Or are you using IDE?
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

Here is image of ACSI driver with 2 partitions - contains movie playback SW test files. Driver self is old, and proven.
http://atari.8bitchip.info/DOAB.rar
I don't have idea what may be the problem in Hatari 1.8 .

In case of IDE and blitter, I'm on writing proper test SW for blitter emulation. Issue is not blitter + IDE combo, since only blitter is used for transfers after driver sets partitions. Of course, normal commands via CPU to $F000xx are given to access other registers.
I post image for it too. Note that long HAV file here is byte-swapped (in compare to other files, physically not byte-swapped actually), because it reads not via hard disk driver in player. Access to partitions only in ST mode, and blitter off.
http://atari.8bitchip.info/DOAB_IDE.rar
As said, will try to find exact blitter emul. error with test SW. And one thing should be added too: reset of IDE device when resetting emulator - as reset line from Atari is connected to reset of IDE disk/CF card .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

I did more tests: tried to read IDE with blitter, with test code in Hatari, with working IDE hard disk image . In all cases I just got 0-s in dest. buffer.
So, for me it looks that blitter simply can not access properly port address $FFF00000 or $F00000 in Hatari. Code for blitter IDE sector read works, just nothing is readen except zeros.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
npomarede
Atari God
Atari God
Posts: 1372
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 1.8.0 has been released

Post by npomarede »

AtariZoll wrote:I did more tests: tried to read IDE with blitter, with test code in Hatari, with working IDE hard disk image . In all cases I just got 0-s in dest. buffer.
So, for me it looks that blitter simply can not access properly port address $FFF00000 or $F00000 in Hatari. Code for blitter IDE sector read works, just nothing is readen except zeros.
Thanks for testing this. I had a look at the blitter's code and it will indeed read/write in RAM and in IO at FFxxxx, but it doesn't handle IDE at F0xxxx, which explains the '0' you got.
I will fix this. By the way, do you know if the blitter will generate some bus errors when accessing a region where the CPU would give a bus error ?
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

Bus error is handled mostly by Glue. It gives bus error to CPU if non-existing address is tried to access and if there is no DTACK in 64 T states (if I remember correct of that value) . + it generates DTACK for all internal HW - in moment depending of their access time - DMA has little longer for instance.
So, I think that in case of Blitter, it is same, as Blitter goes on same bus as CPU . Blitter will get bus error signal from Glue.
In case of IDE port, IDE adapter must take care about DTACK generation, so Glue will not give bus error if DTACK is activated in time.
Note that there are added chips by Atari self, like Real Time Clock, + some others in Mega STE which must take care about DTACK too .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
npomarede
Atari God
Atari God
Posts: 1372
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 1.8.0 has been released

Post by npomarede »

I don't have my STE with me at the moment to test the blitter. If you have time, could you make a small read test with the blitter between ff8010 and ff8040 for example (this does a bus error on STF/STE when using the CPU) ?

I also wonder if the DMA disk triggers a bus error when reading from bus error region ? For example, what happens if we set DMA address to ff8010 and send a write sector command ? Will the cpu crash with a bus error when tryong to read ff8010-ff8210, or will it write '0' bytes ?
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

Eero Tamminen wrote:
AtariZoll wrote:It would be much better and more user friendly if just could set what letter to assign for GEMDOS partition in disk setting menu.
My hard disk driver will not overwrite TOS drives bitmap, but Hddriver overwrites.
It will be than max flexible, and hard disk driver will just create partitions in "free letter slots", in order.
Hatari already checks how many partitions given ACSI image has and doesn't assign GEMDOS HD drive to something overlapping them, but to a first free drive letter after ASCI partitions. Doesn't that work? Or are you using IDE?
AtariZoll???
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

Eero Tamminen wrote:...
AtariZoll???
Zoll is thumb in German.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

npomarede wrote:I don't have my STE with me at the moment to test the blitter. If you have time, could you make a small read test with the blitter between ff8010 and ff8040 for example (this does a bus error on STF/STE when using the CPU) ?

I also wonder if the DMA disk triggers a bus error when reading from bus error region ? For example, what happens if we set DMA address to ff8010 and send a write sector command ? Will the cpu crash with a bus error when tryong to read ff8010-ff8210, or will it write '0' bytes ?
DMA: it totally freezes machine if writing some invalid address to DMA address registers, and after that write block count in. Tried with $600000 and $FFFF8020 . Note that MMU chip is who actually controls addressing of RAM in DMA operations. So, if it gets something out of RAM area - 0-$3FFFFF it will go in some bad state.

I tested: when blitter copies from non-existing address space, it reads $FF-s . There is likely bus error given by Glue, but CPU does not read it, since while blitter is active he is bus master. Well, that was with address set to $600000 . Don't think that different will be with some unused I/O space address .

In any case, this are situations which we hardly will see in any SW, maybe only in case of some crash, but even then unlikely, since there is proper sequence of writes needed to start DMA or blitter .
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

AtariZoll wrote:Here is image of ACSI driver with 2 partitions - contains movie playback SW test files. Driver self is old, and proven.
http://atari.8bitchip.info/DOAB.rar
I don't have idea what may be the problem in Hatari 1.8 .
Boots up fine with EmuTOS. The programs on the disk image don't do any when used as-is. When I give "AL1.HAV" as option, they complation that they couldn't get file location (EmuTOS compatibility issue I guess).

If I use IDE instead of ACSI, also BIGDOS.PRG from AUTO-folder gets run. Then the programs on disk image don't give an error message, they just exit with:

Code: Select all

GEMDOS 0x31 Ptermres(0xAD2C, -21204) at PC 0xFA002A
With TOS 1.04 I get bombs:

Code: Select all

$ src/hatari --trace os_all --conout 2 --acsi DOAB.img 
Hatari v1.8.0, compiled on:  Sep 24 2014, 00:41:06
Building CPU table for configuration: 68000 (compatible mode)
Hard drive image /home/eero/work/hatari/build-gcc/DOAB.img mounted.
Bus Error at address $ff8a00, PC=$fc0ee4 fc0ee0 4a68
BIOS 0x05 Setexc(0x100 VEC_TIMER, 0xFC926C) at PC 0xFC91E8
BIOS 0x00 Getmpb(0x5328) at PC 0xFC9206
BIOS 0x0A Drvmap() at PC 0xFC9206
Gemdos_Boot() at PC 0x8FA0240
BIOS 0x0B Kbshift(0xFFFF) at PC 0x1844
GEMDOS 0x48 Malloc(0x1D4C) at PC 0xFA002A
Bus error wget at 00400000
M68000 Bus Error reading at address $400000 pc=3ffffa
Bus error wget at 00400002
M68000 Bus Error reading at address $400002 pc=3ffffa
Bus Error at address $400000, PC=$3ffffe 3ffffa 0
GEMDOS 0x4C Pterm(-1) at PC 0xFA002A
BIOS 0x05 Setexc(0x102 VEC_TERMINATE, 0xFFFFFFFF) at PC 0xFC9206
Bus error lput at 4e7340e3
Bus error wput at 4e7340e1
Bus error wput at 4e7340d9
Bus error lput at 4e7340db
Bus error wput at 4e7340df
Bus error lput at 4e7340e3
Bus error lput at 4e7340d5
Bus error wput at 4e7340d3
Bus error wput at 4e7340cb
Bus error lput at 4e7340cd
Bus error wput at 4e7340d1
Bus Error at address $4e7340d5, PC=$3fc0b0a fc9374 2f0b
Detected double bus error at address $4e7340d5, PC=$3fc0b0a => CPU halted!
TOS 2.06 looks same except that I don't see the bus errors between Malloc() and Pterm(), but before them:

Code: Select all

Bus Error at address $f00039, PC=$e0166c e01666 4a39
Bus Error at address $f00039, PC=$e0166c e01666 4a39
Four bomb images come on screen before Pterm() with that too though.

If I do in debugger at boot, before the crash:

Code: Select all

> breakpoint GemdosOpcode = 0x4C
> history cpu 256
> setopt -D
I see with the history command that TOS 2.06 bus errrors come from:

Code: Select all

$e01666 : 4a39 fff0 0039                       tst.b     $fff00039
And TOS 1.04 bus errors come from jumping into a memory address with just zeros, which can be caught with:

Code: Select all

> breakpoint (pc) = 0
How the code gets there:

Code: Select all

Gemdos_Boot() at PC 0x8FA0240
BIOS 0x0B Kbshift(0xFFFF) at PC 0x1844
GEMDOS 0x48 Malloc(0x1D4C) at PC 0xFA002A
1. CPU breakpoint condition(s) matched 1 times.
        ( pc ) = 0
CPU=$a84e, VBL=495, FrameCycles=125664, HBL=245, LineCycles=224, DSP=N/A
$00a84e : 0000 0000                            ori.b     #0,d0

> history 4
$001920 : 6600 002a                            bne       $194c
$001924 : 3cbc 0080                            move.w    #$80,(a6)
$001928 : 51f8 043e                            sf        $043e.w
$00192c : 4e90                                 jsr       (a0)
Debugger: *CPU breakpoint*

> r
D0: 00080000 D1: 00000002 D2: 00000008 D3: 0000ffff 
D4: 00000904 D5: 00000001 D6: 0000ffff D7: 00000000 
A0: 0000a84e A1: 0000093a A2: 00000a54 A3: 00fc369c 
A4: 00000000 A5: ffff8604 A6: ffff8606 A7: 0000377a 
USP=00000000 ISP=0000377a MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3
FP0: 0 FP1: 0 FP2: 0 FP3: 0 
FP4: 0 FP5: 0 FP6: 0 FP7: 0 
N=0 Z=0 I=0 NAN=0
prefetch 60242a80
0000a84e: 0000 0000 0000 0000 0000 OR.B #$00,D0
next PC: 0000a852
Then finding when a0 gets bogus value for JSR:

Code: Select all

breakpoint a0 = 0xa84e
It's the Malloc() call return value:

Code: Select all

1. CPU breakpoint condition(s) matched 1 times.
        GemdosOpcode = 0x48
CPU=$187c, VBL=496, FrameCycles=4956, HBL=9, LineCycles=348, DSP=N/A
$00187c : 4e41                                 trap      #1

> next
GEMDOS 0x48 Malloc(0x1D4C) at PC 0xFA002A
CPU=$187e, VBL=496, FrameCycles=13548, HBL=26, LineCycles=236, DSP=N/A
$00187e : 5c8f                                 addq.l    #6,sp

> r
D0: 0000a84e D1: 0000ffff D2: 02fc0b25 D3: 0000ffff 
...
> n
CPU=$1880, VBL=496, FrameCycles=13556, HBL=26, LineCycles=244, DSP=N/A
$001880 : 2040                                 movea.l   d0,a0
After that the code does some register accesses (some to $fffffa01 within a loop) and then:

Code: Select all

$00192c : 4e90                                 jsr       (a0)
Why the non-TOS boot code calls memory address it got with Malloc() from TOS?
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

AtariZoll wrote:
Eero Tamminen wrote:...
AtariZoll???
Zoll is thumb in German.
I meant, could you answer the question of what's the actual problem you have with Hatari's automatic GEMDOS HD emulation drive assignment. :-)
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

Eero Tamminen wrote:...
I meant, could you answer the question of what's the actual problem you have with Hatari's automatic GEMDOS HD emulation drive assignment. :-)
As said, I want that I can set it by my needs, in middle of running Hatari, so not via command line. I usually assign H for GEMDOS drive, so can experiment with ACSI, IDE images, while they will take usual C, D ...
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

Eero Tamminen wrote:
AtariZoll wrote:Here is image of ACSI driver with 2 partitions - contains movie playback SW test files. Driver self is old, and proven.
http://atari.8bitchip.info/DOAB.rar
I don't have idea what may be the problem in Hatari 1.8 .
Boots up fine with EmuTOS. The programs on the disk image don't do any when used as-is. When I give "AL1.HAV" as option, they complation that they couldn't get file location (EmuTOS compatibility issue I guess).
It works not with regular TOS versions. And that means that it step back in compare to older Hatari versions. Player uses very special method to get file location, and no wonder that works not with EmuTOS.
Eero Tamminen wrote: If I use IDE instead of ACSI, also BIGDOS.PRG from AUTO-folder gets run. Then the programs on disk image don't give an error message, they just exit with:

Code: Select all

GEMDOS 0x31 Ptermres(0xAD2C, -21204) at PC 0xFA002A
And again with EmuTOS ? For IDE, there is other image, with IDE in name !
Eero Tamminen wrote: With TOS 1.04 I get bombs:

Code: Select all

$ src/hatari --trace os_all --conout 2 --acsi DOAB.img 
Hatari v1.8.0, compiled on:  Sep 24 2014, 00:41:06
Building CPU table for configuration: 68000 (compatible mode)
Hard drive image /home/eero/work/hatari/build-gcc/DOAB.img mounted.
Bus Error at address $ff8a00, PC=$fc0ee4 fc0ee0 4a68
BIOS 0x05 Setexc(0x100 VEC_TIMER, 0xFC926C) at PC 0xFC91E8
BIOS 0x00 Getmpb(0x5328) at PC 0xFC9206
BIOS 0x0A Drvmap() at PC 0xFC9206
Gemdos_Boot() at PC 0x8FA0240
BIOS 0x0B Kbshift(0xFFFF) at PC 0x1844
GEMDOS 0x48 Malloc(0x1D4C) at PC 0xFA002A
Bus error wget at 00400000
M68000 Bus Error reading at address $400000 pc=3ffffa
Bus error wget at 00400002
M68000 Bus Error reading at address $400002 pc=3ffffa
Bus Error at address $400000, PC=$3ffffe 3ffffa 0
GEMDOS 0x4C Pterm(-1) at PC 0xFA002A
BIOS 0x05 Setexc(0x102 VEC_TERMINATE, 0xFFFFFFFF) at PC 0xFC9206
Bus error lput at 4e7340e3
Bus error wput at 4e7340e1
Bus error wput at 4e7340d9
Bus error lput at 4e7340db
Bus error wput at 4e7340df
Bus error lput at 4e7340e3
Bus error lput at 4e7340d5
Bus error wput at 4e7340d3
Bus error wput at 4e7340cb
Bus error lput at 4e7340cd
Bus error wput at 4e7340d1
Bus Error at address $4e7340d5, PC=$3fc0b0a fc9374 2f0b
Detected double bus error at address $4e7340d5, PC=$3fc0b0a => CPU halted!


TOS 2.06 looks same except that I don't see the bus errors between Malloc() and Pterm(), but before them:

Code: Select all

Bus Error at address $f00039, PC=$e0166c e01666 4a39
Bus Error at address $f00039, PC=$e0166c e01666 4a39
Most of things you listed is caused by TOS code. Like latest with address $F00039 - what is TOS checking is IDE adapter attached.

Eero Tamminen wrote: Four bomb images come on screen before Pterm() with that too though.

If I do in debugger at boot, before the crash:

Code: Select all

> breakpoint GemdosOpcode = 0x4C
> history cpu 256
> setopt -D
I see with the history command that TOS 2.06 bus errrors come from:

Code: Select all

$e01666 : 4a39 fff0 0039                       tst.b     $fff00039
And TOS 1.04 bus errors come from jumping into a memory address with just zeros, which can be caught with:

Code: Select all

> breakpoint (pc) = 0
How the code gets there:

Code: Select all

Gemdos_Boot() at PC 0x8FA0240
BIOS 0x0B Kbshift(0xFFFF) at PC 0x1844
GEMDOS 0x48 Malloc(0x1D4C) at PC 0xFA002A
1. CPU breakpoint condition(s) matched 1 times.
        ( pc ) = 0
CPU=$a84e, VBL=495, FrameCycles=125664, HBL=245, LineCycles=224, DSP=N/A
$00a84e : 0000 0000                            ori.b     #0,d0

> history 4
$001920 : 6600 002a                            bne       $194c
$001924 : 3cbc 0080                            move.w    #$80,(a6)
$001928 : 51f8 043e                            sf        $043e.w
$00192c : 4e90                                 jsr       (a0)
Debugger: *CPU breakpoint*

> r
D0: 00080000 D1: 00000002 D2: 00000008 D3: 0000ffff 
D4: 00000904 D5: 00000001 D6: 0000ffff D7: 00000000 
A0: 0000a84e A1: 0000093a A2: 00000a54 A3: 00fc369c 
A4: 00000000 A5: ffff8604 A6: ffff8606 A7: 0000377a 
USP=00000000 ISP=0000377a MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3
FP0: 0 FP1: 0 FP2: 0 FP3: 0 
FP4: 0 FP5: 0 FP6: 0 FP7: 0 
N=0 Z=0 I=0 NAN=0
prefetch 60242a80
0000a84e: 0000 0000 0000 0000 0000 OR.B #$00,D0
next PC: 0000a852
Then finding when a0 gets bogus value for JSR:

Code: Select all

breakpoint a0 = 0xa84e
It's the Malloc() call return value:

Code: Select all

1. CPU breakpoint condition(s) matched 1 times.
        GemdosOpcode = 0x48
CPU=$187c, VBL=496, FrameCycles=4956, HBL=9, LineCycles=348, DSP=N/A
$00187c : 4e41                                 trap      #1

> next
GEMDOS 0x48 Malloc(0x1D4C) at PC 0xFA002A
CPU=$187e, VBL=496, FrameCycles=13548, HBL=26, LineCycles=236, DSP=N/A
$00187e : 5c8f                                 addq.l    #6,sp

> r
D0: 0000a84e D1: 0000ffff D2: 02fc0b25 D3: 0000ffff 
...
> n
CPU=$1880, VBL=496, FrameCycles=13556, HBL=26, LineCycles=244, DSP=N/A
$001880 : 2040                                 movea.l   d0,a0
After that the code does some register accesses (some to $fffffa01 within a loop) and then:

Code: Select all

$00192c : 4e90                                 jsr       (a0)
Why the non-TOS boot code calls memory address it got with Malloc() from TOS?
Non-TOS boot code ??? That's nonsense. Driver needs to allocate RAM , otherwise it will be overwritten by other programs, AES ... It is not non-TOS bootcode, since uses TOS calls. That jsr (a0) actually calls main driver code to install it in RAM, detect drives, partittions, set buffersm etc. Bootsector code is short, so it can only load main driver code, to allocated RAM area. After all it, rts just returns to TOS, which continues boot process.
Obviously, it jumps to zeros because emulation of loading (main code) with ACSI failed.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

AtariZoll wrote:And again with EmuTOS ? For IDE, there is other image, with IDE in name !
I did it in case you had accidentally given a wrong image (hexdump for the image had string about IDE early on).
AtariZoll wrote:
Eero Tamminen wrote: After that the code does some register accesses (some to $fffffa01 within a loop) and then:

Code: Select all

$00192c : 4e90                                 jsr       (a0)
Why the non-TOS boot code calls memory address it got with Malloc() from TOS?
Non-TOS boot code ??? That's nonsense. Driver needs to allocate RAM , otherwise it will be overwritten by other programs, AES ... It is not non-TOS bootcode, since uses TOS calls. That jsr (a0) actually calls main driver code to install it in RAM, detect drives, partittions, set buffersm etc. Bootsector code is short, so it can only load main driver code, to allocated RAM area. After all it, rts just returns to TOS, which continues boot process.
In case it wasn't clear from the Hatari output, d0 was the Malloc return value (set to d0 by TOS/ROM trap), then non-ROM code moved it to a0. It wasn't modified after that, until "jsr(a0)" call. It didn't call "main driver code", but a pointer to uninitialized memory.
AtariZoll wrote:Obviously, it jumps to zeros because emulation of loading (main code) with ACSI failed.
I'm not (at all) familiar with ACSI, what exactly your code tries to do with ACSI that fails under Hatari?

EDIT: according to "hatari --trace scsi_cmd,gemdos", only ACSI command that is done, is:

Code: Select all

HDC: READ SECTOR (t=0, lun=0, opc=8, cnt=0x1, ctrl=0x0) with LBA 0x0 to 0x181c
-> OK (0)
But that succeeds and is before the Malloc() call, after which your driver crashes.

Hatari ACSI implementation has following changes between Hatari v1.7 and v1.8

Code: Select all

user:        Nicolas Pomarede
date:        Fri Jul 04 01:20:12 2014 +0200
summary:     Store the source of the IRQ in FDC_SetIRQ() + don't set IRQ if already set
user:        Thomas Huth
date:        Tue Dec 17 01:44:54 2013 +0100
summary:     Changed the configuration infrastructure for supporting multiple ACSI devices
user:        Thomas Huth
date:        Sun Oct 27 12:18:36 2013 +0100
summary:     ACSI/SCSI: Fixed handling of unsupported commands
user:        Thomas Huth
date:        Sun Oct 27 11:42:44 2013 +0100
summary:     ACSI/SCSI: Reject reads/writes with illegal sector numbers.
user:        Thomas Huth
date:        Sun Oct 27 11:11:53 2013 +0100
summary:     ACSI: Reset command counters when A1 pin is zero
changeset:   4697:8a7cab1466fd
user:        Thomas Huth
date:        Sun Oct 27 10:35:48 2013 +0100
summary:     ACSI: Get size of image via the size of the file instead of using the MBR.
user:        Thomas Huth
date:        Sat Oct 26 13:01:14 2013 +0200
summary:     ACSI/SCSI: Fill INQUIRY buffer with more sane values.
changeset:   4684:ca5439819515
user:        Thomas Huth
date:        Sun Oct 06 21:27:54 2013 +0200
summary:     SCSI: First steps towards Falcon NCR5380 register handling
user:        Thomas Huth
date:        Mon Oct 21 23:49:15 2013 +0200
summary:     Fix the handling of SCSI commands with opcode >= 0x40.
user:        Thomas Huth
date:        Mon Oct 21 22:24:11 2013 +0200
summary:     READ CAPACITY updated the DMA counter to a wrong value.
user:        Thomas Huth
date:        Mon Oct 21 22:00:40 2013 +0200
summary:     According to the SCSI standard, INQUIRY must also be handled for unknown LUNs.
user:        Thomas Huth
date:        Fri Sep 27 16:12:16 2013 +0200
summary:     Fixed READ CAPACITY command for ACSI hard disk images.
Does any of them ring any bells for what your code tries to do?
Last edited by Eero Tamminen on Fri Sep 26, 2014 9:09 pm, edited 2 times in total.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

AtariZoll wrote:
Eero Tamminen wrote:...
I meant, could you answer the question of what's the actual problem you have with Hatari's automatic GEMDOS HD emulation drive assignment. :-)
As said, I want that I can set it by my needs, in middle of running Hatari, so not via command line. I usually assign H for GEMDOS drive, so can experiment with ACSI, IDE images, while they will take usual C, D ...
Yes, but what is your problem with Hatari?

I'm normally using command line so that things are set up right from the beginning, but I just tested setting things up in GUI when Hatari's already running, and that works fine too. I select GEMDOS HD directory and ACSI image and OK the settings, Hatari says that it needs to reboot, and after that ACSI image partitions start from C: and GEMDOS HD drive is after those.
AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Hatari 1.8.0 has been released

Post by AtariZoll »

It is not 0 in d0 returned after Malloc call, but:
"GEMDOS 0x48 Malloc(0x1D4C) at PC 0xFA002A
CPU=$187e, VBL=496, FrameCycles=13548, HBL=26, LineCycles=236, DSP=N/A
$00187e : 5c8f addq.l #6,sp

> r
D0: 0000a84e D1: 0000ffff D2: 02fc0b25 D3: 0000ffff "
$084E is exactly address what returns in TOS 1.04 in boot stage. So, Malloc was performed properly. So, I really don't know where you see 0 . Beside it, tracing some SW by looking only Traps and CPU exceptions is not the best idea. What is there not visible is loading of 6 sectors from ACSI disk, namely sectors 2-7 , which contain driver TOS exec, packed as SFX . That ACSI loader in bootsector is very basic, using only read command .
I can give source of it here.
Btw. there is added $80E4 (space for buffers + basepage) to a0 before jsr (a0), so no jump to 0 can happen at all.

This part may be problem:

Code: Select all

 move.w #8,d0   *Read command
  swap d0
  move.w #$0088,d0  *single byte access
  bsr wcbytea    *  This writes to DMA chip, and tests interrupt after
  bne dma_erra
Proper is to use #$008A,d0 , because #$0088 works not well if more than 1 ACSI device is attached. But with 1 device it works fine, and in Hatari there is no support for more.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

AtariZoll wrote:$084E is exactly address what returns in TOS 1.04 in boot stage. So, Malloc was performed properly. So, I really don't know where you see 0 . Beside it, tracing some SW by looking only Traps and CPU exceptions is not the best idea.
You complained about a crash, so I looked why it crashed. That was due to jump to an address that contained zeroes instead of valid instructions. And yes, Malloc returns a valid address (as was visible from Hatari debugger output I posted). But the content in that adress is untouched by your driver after the Malloc call (and happened to be zeros because this was soon enough after boot that nothing had dirtied that area of memory). However, your code still jumps to that address (containing uninitialized content). I think we're clear on that. :-)
AtariZoll wrote: Btw. there is added $80E4 (space for buffers + basepage) to a0 before jsr (a0), so no jump to 0 can happen at all.
Nothing was added to the address returned by Malloc, before or after that value was assigned to a0.
AtariZoll wrote: What is there not visible is loading of 6 sectors from ACSI disk, namely sectors 2-7 , which contain driver TOS exec, packed as SFX .
And when this additional ACSI sector read reading should happen:
- Before Malloc() call, or
- After Malloc() call, but before your driver jumps to address returned by Malloc()
?
AtariZoll wrote: That ACSI loader in bootsector is very basic, using only read command .
I can give source of it here.

This part may be problem:

Code: Select all

 move.w #8,d0   *Read command
  swap d0
  move.w #$0088,d0  *single byte access
  bsr wcbytea    *  This writes to DMA chip, and tests interrupt after
  bne dma_erra
Please provide code also for "wcbytea", or debug symbols information for your driver, so that I can use debugger to disassemble the code with subroutine names (I don't know ACSI, and I've never used DMA on Atari, so I need more info to track down from Hatari sources, what happens when your code does certain things).
AtariZoll wrote: Proper is to use #$008A,d0 , because #$0088 works not well if more than 1 ACSI device is attached.
But with 1 device it works fine, and in Hatari there is no support for more.
Hatari v1.8 has support for up to 8 ACSI devices, although only one is "user-visible". You need to specify images for device 1-7 manually in the config file though (for [ACSI] section). And I don't know how much support for multiple ACSI devices is tested...
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2433
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 1.8.0 has been released

Post by Eero Tamminen »

Hm. Seems that HDC (ASCI) goes through FDC. FDC trace shows that after Malloc there are some things which are indicated to be for HDC (DMA mode bits match 0x0008), however they apparently fail to match what HDC code expects.

Do the traced FDC HDC commands for your code look as expected in the attached trace?

Here's the first of them after Malloc:

Code: Select all

GEMDOS 0x48 Malloc(0x1D4C) at PC 0xFA002A
fdc write dma address ff860d val=0xb2 address=0x18b2 VBL=1442 video_cyc=63352 184@282 pc=16c2
fdc write dma address ff860b val=0xcc address=0xccb2 VBL=1442 video_cyc=63372 204@282 pc=16c8
fdc write dma address ff8609 val=0x00 address=0xccb2 VBL=1442 video_cyc=63392 0@283 pc=16ce
fdc write 8606 ctrl=0x198 VBL=1442 video_cyc=63420 28@283 pc=16d4
fdc reset dma VBL=1442 video_cyc=63420 28@283 pc=16d4
fdc write 8606 ctrl=0x98 VBL=1442 video_cyc=63436 44@283 pc=16d8
fdc reset dma VBL=1442 video_cyc=63436 44@283 pc=16d8
fdc write 8604 data=0x8 VBL=1442 video_cyc=63452 60@283 pc=16da
fdc write 8604 dma sector count=0x8 VBL=1442 video_cyc=63452 60@283 pc=16da
fdc write 8606 ctrl=0x88 VBL=1442 video_cyc=63464 72@283 pc=16de
fdc write 8604 data=0x8 VBL=1442 video_cyc=63520 128@283 pc=175a
fdc write 8604 hdc command addr=0 command=0x8 VBL=1442 video_cyc=63520 128@283 pc=175a
You do not have the required permissions to view the files attached to this post.
User avatar
npomarede
Atari God
Atari God
Posts: 1372
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 1.8.0 has been released

Post by npomarede »

Eero Tamminen wrote:Hm. Seems that HDC (ASCI) goes through FDC. FDC trace shows that after Malloc there are some things which are indicated to be for HDC (DMA mode bits match 0x0008), however they apparently fail to match what HDC code expects.

Do the traced FDC HDC commands for your code look as expected in the attached trace?
FDC and HDC share the same IO registers at $ff86xx, so it's normal to set dma address for FDC at $ff8609/0b/0d for example.
In Hatari, traces print "fdc" but that's because in most cases (games and demos), you don't have HDC access, so it makes a shorter ouptut. Only bits 7 and 3 in $ff8606 will tell if you're accessing the hdc or the fdc.
Post Reply

Return to “Hatari”