I have created a Github repo for my custom 560Z utility package.
https://github.com/TangentDelta/OSI-560Z-Utils_Modified
Not all features of the package have been fully tested, so there are most likely some bugs in the utility routines I haven't had to use yet.
If anybody is interested in some pre-built binary releases let me know. I need to know what memory address it should be built at, the base address of the 560Z, and what ACIA is to be used.
560Z Utility Package
-
- Posts: 233
- Joined: Tue Dec 09, 2014 12:53 am
Re: 560Z Utility Package
This is great, I was trying to add some more functionality to the 6100 like memory manager as the way it is it only does one bank of memory, i ran focal on it but most pdp software need the memory calls, i did not get very far and it went down the list of projects. have you look at adding any extra to the 6100 , memory ,disk etc.
cheers
cheers
Replica 600 Rev D:8K,CEGMON
Replica 610 Rev B: 24k,MPI B-51 with Custom Data separator D-13
510 on the bench/replica 582 backplane/replica 470a /replica 555/original 570B/2 x Shugart 851
Ongoing : 630 ,620 ,510,542c,custom 590,SA1200,592,594,596,598
Replica 610 Rev B: 24k,MPI B-51 with Custom Data separator D-13
510 on the bench/replica 582 backplane/replica 470a /replica 555/original 570B/2 x Shugart 851
Ongoing : 630 ,620 ,510,542c,custom 590,SA1200,592,594,596,598
-
- Posts: 12
- Joined: Tue Feb 20, 2018 12:48 am
Re: 560Z Utility Package
Yes. My current project is to implement the PDP-8 memory management unit. The KM8E changes its internal registers when certain instructions are executed. For example, when a JMP is executed, the instruction field buffer register is moved into the instruction field register. The only way to implement this without modifying the 560Z hardware is to run the 6100 in single-step mode and compare every instruction when an instruction field change is pending.
As for the disk drive, I plan on using Kyle Owen's disk drive server.
https://github.com/drovak/os8diskserver
I'm working on getting a 550 serial card going in my system so that I'll have plenty of serial ports.
-
- Posts: 12
- Joined: Tue Feb 20, 2018 12:48 am
Re: 560Z Utility Package
I have the data field and instruction field functionality of the KM8-E implemented in my driver package. It passes all of my quick and dirty test programs, but I'd like to try something a bit more intensive on it. I will have to find a PDP-8 memory extension test program, or a programming language that uses it.
-
- Posts: 233
- Joined: Tue Dec 09, 2014 12:53 am
Re: 560Z Utility Package
Replica 600 Rev D:8K,CEGMON
Replica 610 Rev B: 24k,MPI B-51 with Custom Data separator D-13
510 on the bench/replica 582 backplane/replica 470a /replica 555/original 570B/2 x Shugart 851
Ongoing : 630 ,620 ,510,542c,custom 590,SA1200,592,594,596,598
Replica 610 Rev B: 24k,MPI B-51 with Custom Data separator D-13
510 on the bench/replica 582 backplane/replica 470a /replica 555/original 570B/2 x Shugart 851
Ongoing : 630 ,620 ,510,542c,custom 590,SA1200,592,594,596,598
-
- Posts: 12
- Joined: Tue Feb 20, 2018 12:48 am
Re: 560Z Utility Package
The memory extension functionality has been implemented in my testing environment and passes my quick and dirty tests. I'm in the process of getting the DEC memory extension utility running to test it fully, but I need to rework some major parts of the driver package to support un-halting the 6100 after it encounters a HLT instruction. The DEC utility halts the CPU so that the user can change the switch register and then hit the "continue" switch on the PDP-8's front panel.
In the mean time, I have modified the utility package's BIN loader. My modified version loads the BIN-formatted tape image directly into the SYS bus memory, supports data field changes (more than 4K of memory), and is slightly smaller in size.
In the mean time, I have modified the utility package's BIN loader. My modified version loads the BIN-formatted tape image directly into the SYS bus memory, supports data field changes (more than 4K of memory), and is slightly smaller in size.
Code: Select all
;Enhanced BIN loader for 6100
;Load directly into the SYS memory
;Supports field changes (more than 4K words)
BINLDR:
lda #0 ;Clear high pointer
sta PNTH
lda DSTL
sta OCTAL
lda DSTH
sta OCTAH
BINL0:
jsr REDCHR ;Skip through leader
cmp #$80
beq BINL0
bne BINL1A
BINL1:
LDA #0
sta PNTH
jsr REDCHR
BINL1A:
bit SC0 ;Skip special case checking if upper two bits are 0
beq DATAFD
bit S80 ;Check if a control code
bne FIELDQ
CHGORIG: ;Change data origin
jsr TWELV
sta OCTAL
stx OCTAH
jmp BINL1
FIELDQ:
bit S40 ;Check if trailer is encountered
beq END
FIELDC: ;Change field
asl a ;Shift field data into correct position
and #%01110000 ;Mask off field bits
ora OCTAH ;Set upper bits of pointer to new field
;Write OCTDL,OCTDH into (OCTAL,OCTAH)
jmp BINL1
END:
rts
DATAFD: ;Load data into field
jsr TWELV
sta OCTDL
txa
sta OCTDH
jsr WRITEO
inc OCTAL
bne BINL1
lda #'.'
jsr OUTCH
inc OCTAH
jmp BINL1
TWELV: ;Get two bytes and create a 12-bit pointer
asl a ;Shift high 6 bits into position
asl a
ldx #4
TW1:
asl a ;Shift raw data into high pointer
rol PNTH
dex
bne TW1
sta PNTL
jsr REDCHR
ora PNTL
ldx PNTH
rts
S40: .byte $40
S80: .byte $80
SC0: .byte $C0
-
- Posts: 12
- Joined: Tue Feb 20, 2018 12:48 am
Re: 560Z Utility Package
Implementing a "supervisor" console is proving to be a bit trickier than I had anticipated. The most logical solution to the problem is to re-write the 6100 driver package to be called via an interrupt service routine. This requires an interrupt service routine, which I do not have implemented.
My concern is that the modifications I'm making will limit the accessibility of the driver package. If I go the route of making it interrupt-driven, you would have to make the necessary modifications to your 560Z board and ACIA board. The "supervisor" console would also require multiple ACIAs in the form of the 550 board, which has not yet been reproduced.
The "core" version of the driver package (on Github) is enough to run FOCAL, which I imagine should be fine for most use cases.
My concern is that the modifications I'm making will limit the accessibility of the driver package. If I go the route of making it interrupt-driven, you would have to make the necessary modifications to your 560Z board and ACIA board. The "supervisor" console would also require multiple ACIAs in the form of the 550 board, which has not yet been reproduced.
The "core" version of the driver package (on Github) is enough to run FOCAL, which I imagine should be fine for most use cases.
-
- Posts: 12
- Joined: Tue Feb 20, 2018 12:48 am
Re: 560Z Utility Package
The interrupt-driven I6100 IOT driver is working...more or less. There are some timing issues with the "teleprinter clear flag set" interrupt due to the relative slowness of the I6100 and the speed at which the ACIA can transmit a character at 9600 baud. I had to add a delay loop to the interrupt generator and set up the interrupt handler to perform recurrent interrupts in certain states.
The best solution to this issue would be to have a programmable timer to generate an interrupt for the 6502 in order to generate an interrupt for the I6100. I'm not aware of any OSI boards with programmable timers, so one would have to be designed.
As for "hardware-accelerating" the memory extension feature, I have an untested idea. I should be able to AND the DATAF pin of the 6100 with the CA2 pin of a PIA in order to feed a diode that connects to the "trap" line. When the data field differs from the instruction field, the CA2 flag on the PIA would be set. When an indirect instruction is executed, an interrupt is generated via the hardware mod I made previously ("halt" line tied to CA1) and the ISR can poll the "DATAF" bit on the PIA in order to take the appropriate action.
The best solution to this issue would be to have a programmable timer to generate an interrupt for the 6502 in order to generate an interrupt for the I6100. I'm not aware of any OSI boards with programmable timers, so one would have to be designed.
As for "hardware-accelerating" the memory extension feature, I have an untested idea. I should be able to AND the DATAF pin of the 6100 with the CA2 pin of a PIA in order to feed a diode that connects to the "trap" line. When the data field differs from the instruction field, the CA2 flag on the PIA would be set. When an indirect instruction is executed, an interrupt is generated via the hardware mod I made previously ("halt" line tied to CA1) and the ISR can poll the "DATAF" bit on the PIA in order to take the appropriate action.