Hi all
Oops that went off before I was finished with it.
>I suspect that I can figure out from the pattern of I/O accesses
>which devices are at which address in the memory map, at least if I
>bring up an emulation in MAME. That should at least allow writing
>new code for it, and _maybe_ even figuring out which CRT controller
>the video hardware uses and where in the memory map it is. (I
>suspect the 6845 and/or 6847 just from the time period, but who
>knows? Gotta see what it actually do when trying to show the âIPL
>IN PROGRESSâ string contained in the ROM, or one of the couple
>error strings )
As far as I can tell this is where a character gets displayed.
; character in +1(A6)
00FFCE0C : 48E7 C000 MOVEM.L D0,D1,-(A7)
00FFCE10 : 302B 06AC MOVE.W +1708(A3),D0 ; get something
00FFCE14 : 6122 BSR $00FFCE38 ; do something
00FFCE16 : 0040 8000 ORI.W #$8000,D0
00FFCE1A : 11C0 8001 MOVE.B D0,$00FF8001 ; Low byte
00FFCE1E : E048 LSR.W #8,D0
00FFCE20 : 11C0 8003 MOVE.B D0,$00FF8003 ; High byte
00FFCE24 : 11EE 0001 8005 MOVE.B +1(A6),$00FF8005 ; Character
00FFCE2A : 0838 0006 801B BTST #6,$00FF801B ; Wait
for a flag
00FFCE30 : 66F8 BNE $00FFCE2A
00FFCE32 : 4CDF 0003 MOVEM.L (A7)+,D0,D1
00FFCE36 : 4E75 RTS
; Here with something (from $06AC(A3)) in D0
; current guess, it's the cursor position, which then gets translated
; to an X and a Y byte in D0.w
00FFCE38 : 0C2B 0050 06B7 CMPI.B #$50,+1719(A3)
00FFCE3E : 6628 BNE $00FFCE68 ; Return
00FFCE40 : 48C0 EXT.L D0
00FFCE42 : 81FC 0050 DIVS #$0050,D0
00FFCE46 : 4840 SWAP D0
00FFCE48 : 3200 MOVE.W D0,D1
00FFCE4A : 4840 SWAP D0
00FFCE4C : ED48 LSL.W #6,D0
00FFCE4E : 0C01 0040 CMPI.B #$40,D1
00FFCE52 : 6C08 BGE $00FFCE5C
00FFCE54 : 11FC 0000 8013 MOVE.B #$00,$00FF8013
00FFCE5A : 600A BRA $00FFCE66
00FFCE5C : 0441 0040 SUBI.W #$0040,D1
00FFCE60 : 11FC 0001 8013 MOVE.B #$01,$00FF8013
00FFCE66 : 8041 OR.W D1,D0
00FFCE68 : 4E75 RTS
Or maybe it's talking to a chip (not 6845 which is memory mapped or
7220 which has two registers only) and someone recognises it?
W
Hi all
Chris gave me a copy of the boot ROM and I played around with it a bit.
>I threw the 4KB of boot ROM in Ghidra and confirmed a couple things:
>
>- At boot, ROM is mapped to 0, and then remapped either by a write
>to the location or by a cycle counter: The initial stack pointer at
>0x0 is 0x0001fffe and the initial program counter at 0x4 is
>0x00ffc026, indicating the ROM is normally located at 0x00ffc000.
>- The ROM freely interchanges addresses in the
>0x00ffc000..0x00ffffff range and addresses in the
>0xffffc000..0xffffffff range, which is annoying to deal with in Ghidra.
The code takes advantage of the 68000 sign-extend on absolute short
addressing mode, like move.b #$00, $8011. IDA correctly disassembles
this to "move.b #0,($FF8011).w". I assume Ghidra if sign-extending
it all the way to FFFF8011?
>- I/O devices appear to be in the 0x00ff8000..0x00ffbfff range, all
>of the devices accessed via the bootstrap seem to be barely above 0x00ff8000.
>- Only NMI, bus error, interrupt 2, and interrupt 5 are set up by
>the bootstrap.
Yup.
>- The bootstrap is very bare-bones but still has a bunch of
>indirection in it; itâs obviously written in assembly, but it does
>seem to have parameterization so it may support both console and serial I/O.
I suspect either some low-level high-level language, or massive use
of macros (which is in effect a low-level high-level language :-) Code like:
; Called with A6 pointing to a length and a string address
00FFCA4C : 48E7 8080 MOVEM.L D0,A0,-(A7)
00FFCA50 : 3016 MOVE.W (A6),D0 ; length
00FFCA52 : 48C0 EXT.L D0
00FFCA54 : 206E 0002 MOVEA.L +2(A6),A0 ;
pointer to string
00FFCA58 : 508E ADDQ.L #8,A6 ; clear stack
00FFCA5A : 5380 SUBQ.L #1,D0
00FFCA5C : 6B0E BMI $00FFCA6C ; done
00FFCA5E : 518E SUBQ.L #8,A6 ;
make space on stack again
00FFCA60 : 1D58 0001 MOVE.B (A0)+,+1(A6) ;
one character on stack
00FFCA64 : 4EB8 C566 JSR $00FFC566
00FFCA68 : 51C8 FFF4 DBF D0,$00FFCA5E ; loop
00FFCA6C : 4CDF 0101 MOVEM.L (A7)+,D0,A0
00FFCA70 : 4E75 RTS
>I suspect that I can figure out from the pattern of I/O accesses
>which devices are at which address in the memory map, at least if I
>bring up an emulation in MAME. That should at least allow writing
>new code for it, and _maybe_ even figuring out which CRT controller
>the video hardware uses and where in the memory map it is. (I
>suspect the 6845 and/or 6847 just from the time period, but who
>knows? Gotta see what it actually do when trying to show the âIPL
>IN PROGRESSâ string contained in the ROM, or one of the couple
>error strings )
> Chris
I remember circa 1977 CMU had a PDP-11 compiler for '68 with an extensive
runtime component.
I presume the sources are lost.
Peter Hibbard was the guy responsible if I recall.
Evangelist of lean software and devisor of 9 programming languages and
an OS was 89
https://www.theregister.com/2024/01/04/niklaus_wirth_obituary/
The great man has left us. I wrote an obituary.
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 277612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
Does anyone here has an actual IMF file (Internal Machine Fix) for the IBM
5110? Not the file called "IMF" on the Customer Support Functions
disk/tape, but a real fix. File type should be 23.
I am trying to figure out how the patch mechanism works. The IMF is
supposed to be loaded with the LOADER utility.
Christian
