View Single Post
Old 11th May 2021, 6:28 pm   #6
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,363
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Just a thought as well - most of the programs are available in HEX format already so you may be best using known good ones to create the punch requests... If you have an EPROM programmer the software is a quick and easy way to load the Intel HEX file and then export a binary block... Other programs are available at the command line to do this especially in Linux...

I have also been thinking that the bare binary format would be a problem for the split address used with the expanded memory on the MK14 - e..g SEGTRIS uses the full 512 bytes at both B00 and F14 - it is a risk overwriting the bytes at 0F00-0F14 so you would need the safe values in there - or maybe not as the RESET would wipe them anyway. You then would write a file from B00-FFF as is and allow the boot loader to read and throw away the NULLS that would be included.

Then you have to cross the two IO shadows at C00 and E00 so you would need to ensure the image on the tape at this points was your boot loader as it would get overwritten. I suppose the other values need to be clever for the INS8154 as well as the config would change as the read/write passed over there

The KB and Display Shadow may cause the display to be funny but, should be risk free.

The best solution would be a small pre-amble so the minimal boot loader loads a small longer loader in the 8154 RAM which then knows how to skip writing when in the C,D and E pages... or make that part of the loader - it will probably only add a few bytes and makes the paper tapes more universal.

The Memory map
-----------------------

Only the first 12 bits of the program counter are decoded - the remainder are
present on the Data Bus so need to be latched for decoding - note that SCIOS
relies on the wrap from FFF to 000 in the lower 4K making memory expansion more
difficult. The "decoded by" fields cover A11-A8 - A7-A0 are within 256 slot...

000-1FF 512 byte SCIOS ROM Decoded by 0xxx - see mod to A11 for expansion

200-3FF ROM Shadow / Expansion RAM
400-5FF ROM Shadow / Expansion RAM
600-7FF ROM Shadow / Expansion RAM

800-87F I/O Ports Decoded by 1xx0
800-824 are control registers
800-807 - Clear BIT port A
808-80F - Clear BIT port B
810-817 - Set BIT port A
818-81F - Set BIT port B
820 Read/Write Port A
821 Read/Write Port B
822 Port A direction register D BUS (ACC) to ODA (1 = Output, 0 = Input)
823 Port B direction register D BUS (ACC) to ODB (1 = Output, 0 = Input)
823 Port B Mode Definition Reg D BUS (ACC) to MDR
7 6 5 4-0 (Port B Bit 7 Input, Bit 6 - Output to use this mode)
x x 0 xxxxx - BASIC I/O
x 0 1 xxxxx - STROBED INPUT
0 1 1 xxxxx - STROBED OUTPUT
1 1 1 xxxxx - STROBED OUTPUT WITH TRI-STATE
825-87F undefined

880-8FF 128 bytes I/O chip RAM Decoded by 1xx0

900-9FF Keyboard & Display Decoded by 1x01
900 Left Digit 1 (see later table of letters etc)
-
908 Right Digit 8
A00-AFF I/O Port & RAM Shadow
B00-BFF 256 bytes RAM (Extended) / VDU RAM Decoded by 1011

User programs

C00-CFF I/O Port & RAM Shadow
D00-DFF Keyboard & Display Shadow - Used by SCIOS for Tape as 0D5 and 0D6

E00-EFF I/O Port & RAM Shadow (used by some programs e.g. CT Life)

F00-FFF 256 bytes RAM (Standard) / VDU RAM Decoded by 1111

F00-F11 are used by ROM Monitor (document)
F00 - Right most digit on display
..
F07 - Left most digit on display (shown by calling KYBD in SCIOS)
F08
..
F11

F12 onwards for User programs - usually variables... for -ve relative access

F20 convention for Start of User programs.

Stack Pointer P2 by convention in Williamson book starts at FF8 and grows
down in memory (the book uses the other term that increasing address is down
which can confuse the reader...) The pointer is always pointing at the last
filled address by this convention.

Top bytes are used by ROM monitor for register store for GO
FF9 P1 High
FFA P1 Low
FFB P2 High
FFC P2 Low
FFD A
FFE E
FFF S

This is the bit that relies on the address wrap...
Timbucus is offline