Stack and subroutine calls - Page 2 - UK Vintage Radio Repair and Restoration Discussion Forum

River25 · 7th Apr 2023, 12:16 am

I run a 74HC154 on my SC/MP II SBC as it breaks down the 64k into the same 4k pages as the SC/MP. Doesn't solve software issues of going over the page boundary, but it does neatly package the 4k pages in accordance to how the SC/MP sees its memory.

Phil__G · 7th Apr 2023, 9:49 am

What we need ideally is a 154 with latched inputs

Michael Haardt · 7th Apr 2023, 2:32 pm

What do you use the 154 for? I don't see how that adds banking.

tritone · 7th Apr 2023, 6:23 pm

Hell,

I dunno what you's guys are talking about, Mumbo Jumbo,

Im C, C++, Assembly on the HC6500, Java, 1's and 0's, Hex,

Education/Hello/World/carriagereturn;

Mark1960 · 7th Apr 2023, 6:37 pm

Quote:

Originally Posted by Phil__G

What we need ideally is a 154 with latched inputs

Closest I’ve seen is ‘547, but thats only three bits.

I think the ‘193 works quite well, with count inputs grounded you get carry and borrow outputs for top and bottom 4k pages. With modern sram large enough to fill 64k the borrow output can provide decoding for 4k rom, or connect A11 to borrow input for 2k rom and 2k ram. Carry output provides decode for a 4k input/output page. This probably still needs at least one more AND gate to disable ram for both the top and bottom 4k pages.

River25 · 7th Apr 2023, 10:27 pm

Hi,

Quote:

Originally Posted by Michael Haardt

What do you use the 154 for? I don't see how that adds banking.

It's not for banking. It's just for breaking down the CPU memory map into 4k chunks. It just seemed the right choice and number of selects that suits the SC/MP.

For the 2650 CPU I would break it down into 8k pages, as that is what it uses by default. It could be broken down into lesser or greater chunks. It doesn't make any difference to the CPU.

river

River25 · 12th Apr 2023, 12:21 pm

Sorry to drag this topic up again, but as I am going through my SC/MP system, I have a compromise I need to make in regard to saving registers. The original Kitbug, which was what Nat Semi used for their SC/MP systems, had a very crude stack, which was implemented by using the roll-over of the first 4k page of memory. It used PC relative addressing to save the register values and used the same method to drag them back. However, it did not save or restore the P3 register, as this was the only entry back into Kitbug.

I am not familiar with Elbug, but I assume it is the Elektor version of Kitbug? Does it save every register and is capable of restoring them all? Like a true breakpoint requirement? Also, does the Mk14 have this ability? I am not familiar with the Mk14 either.

I am somewhat familiar with the SC/MP LCDS (Low-Cost Development System), having access to all its code listings and circuit diagrams, and they get quite sneaky by using a small hardware circuit, which is activated when the "debug" switch is enabled. This starts a clock which feeds a small 32-byte PROM which does dummy reads on the SC/MP application card (which it assumes is slotted into one of the LCDS sockets) that enables this PROM to grab the data from the SC/MP registers and puts them into the RAM area of the LCDS. Once this data has been collected the user can go into the RAM to look and edit the values which, when hitting the "run" switch on the LCDS, will load the relevant SC/MP registers with the data and away she runs. Very nifty, but it is not something I intend to do on my system. I think my system can save everything except P2, as I have used P2 to save all my previous registers. I am scratching my head on this, so any pointers (no pun intended) will be useful.

river

Michael Haardt · 12th Apr 2023, 5:22 pm

Elbug is not related to Kitbug at all. It does have a stack which saves and restores all registers and it offers a breakpoint. There must be some shortcoming in its breakpoint implementation, because that was changed a whole lot in Elbug II. I didn't really understand the code, but it may be that Elbug only stores "xppc p3" as breakpoint and Elbug II stores a whole sequence of code there.

I never thought about it up to now, but indeed the SC/MP lacks any kind of system call instruction.

Michael

Mark1960 · 12th Apr 2023, 5:32 pm

The MK14 saves P3+1 when user program returns to the monitor, the monitor adds one. As the return to the monitor uses XPPC P3 this is actually PC+1. The user program P3 is known and constant, this is the entry point to the monitor, if not correct then the user program could not return to the monitor. If Go is pressed the monitor subtracts one from the saved P3 and then uses XPPC P3 to execute user program. This XPPC P3 is followed by a jump to the monitor entry point. I think Kitbug is the same as the MK14 monitor.

The MK14 has an add on circuit using a counter to implement single step debug using sense A as an interupt. There is a halt instruction in the monitor and the halt status on the data bus during NADS resets the counter, then the interupt is enabled before the XPPC P3, the counter then interupts the user program during execution of the first instruction and returns to the monitor.

In my multiprocessor I use this halt instruction to free the next processor from reset, while the first processor continues the user program. The processor released from reset then starts running the monitor.

The LCDS 32 byte prom seems similar to memory paging used on CPM systems for the boot prom, which is then switched out to give full 64k ram. I’d be interested in seeing the LCDS schematic to see how they do that.

SiriusHardware · 12th Apr 2023, 7:37 pm

Quote:

I think Kitbug is the same as the MK14 monitor.

I think 'KITBUG' is the OS which was used by the National Introkit in its basic form without a keyboard and display, where it communicated over TTY.

The name given to the OS for the National Introkit + Keyboard and Display was 'SCMPKB', and the old / original MK14 OS is byte for byte identical to that one.

The 'New' MK14 OS is a revamped version which requires fewer keypresses per databyte entry and adds built in jump offset calculator, cassette load and save routines and firmware support for the optional single-step hardware.

I wonder if anyone, anywhere, is running the 'new' MK14 OS in a National Introkit + Keyboard and Display?

Michael Haardt · 22nd Apr 2023, 6:59 pm

The LCDS schematics and manual are here:

http://www.bitsavers.org/components/national/scmp/

It looks as if the debug switch sets a flipflop that switches the address bus multiplexers from the CPU address bus to a clock triggered counter, so the CPU executes instructions from a different address than its PC. It is interesting that they recognized the lack of any exception or software interrupt early on, but did not add that to the CPU.

7th Apr 2023, 12:16 am	#21
River25 Triode Join Date: Apr 2023 Location: Sydney New South Wales, Australia. Posts: 31	Re: Stack and subroutine calls I run a 74HC154 on my SC/MP II SBC as it breaks down the 64k into the same 4k pages as the SC/MP. Doesn't solve software issues of going over the page boundary, but it does neatly package the 4k pages in accordance to how the SC/MP sees its memory.

7th Apr 2023, 9:49 am	#22
Phil__G Octode Join Date: Mar 2011 Location: North Yorkshire, UK. Posts: 1,115	Re: Stack and subroutine calls What we need ideally is a 154 with latched inputs

7th Apr 2023, 2:32 pm	#23
Michael Haardt Tetrode Join Date: May 2021 Location: Titz, Germany. Posts: 72	Re: Stack and subroutine calls What do you use the 154 for? I don't see how that adds banking.

7th Apr 2023, 6:23 pm	#24
tritone Banned Join Date: Nov 2014 Location: Derry, Northern Ireland, UK. Posts: 167	Re: Stack and subroutine calls Hell, I dunno what you's guys are talking about, Mumbo Jumbo, Im C, C++, Assembly on the HC6500, Java, 1's and 0's, Hex, Education/Hello/World/carriagereturn;

12th Apr 2023, 12:21 pm	#27
River25 Triode Join Date: Apr 2023 Location: Sydney New South Wales, Australia. Posts: 31	Re: Stack and subroutine calls Sorry to drag this topic up again, but as I am going through my SC/MP system, I have a compromise I need to make in regard to saving registers. The original Kitbug, which was what Nat Semi used for their SC/MP systems, had a very crude stack, which was implemented by using the roll-over of the first 4k page of memory. It used PC relative addressing to save the register values and used the same method to drag them back. However, it did not save or restore the P3 register, as this was the only entry back into Kitbug. I am not familiar with Elbug, but I assume it is the Elektor version of Kitbug? Does it save every register and is capable of restoring them all? Like a true breakpoint requirement? Also, does the Mk14 have this ability? I am not familiar with the Mk14 either. I am somewhat familiar with the SC/MP LCDS (Low-Cost Development System), having access to all its code listings and circuit diagrams, and they get quite sneaky by using a small hardware circuit, which is activated when the "debug" switch is enabled. This starts a clock which feeds a small 32-byte PROM which does dummy reads on the SC/MP application card (which it assumes is slotted into one of the LCDS sockets) that enables this PROM to grab the data from the SC/MP registers and puts them into the RAM area of the LCDS. Once this data has been collected the user can go into the RAM to look and edit the values which, when hitting the "run" switch on the LCDS, will load the relevant SC/MP registers with the data and away she runs. Very nifty, but it is not something I intend to do on my system. I think my system can save everything except P2, as I have used P2 to save all my previous registers. I am scratching my head on this, so any pointers (no pun intended) will be useful. river

12th Apr 2023, 5:22 pm	#28
Michael Haardt Tetrode Join Date: May 2021 Location: Titz, Germany. Posts: 72	Re: Stack and subroutine calls Elbug is not related to Kitbug at all. It does have a stack which saves and restores all registers and it offers a breakpoint. There must be some shortcoming in its breakpoint implementation, because that was changed a whole lot in Elbug II. I didn't really understand the code, but it may be that Elbug only stores "xppc p3" as breakpoint and Elbug II stores a whole sequence of code there. I never thought about it up to now, but indeed the SC/MP lacks any kind of system call instruction. Michael

12th Apr 2023, 5:32 pm	#29
Mark1960 Octode Join Date: Mar 2020 Location: Kitchener, Ontario, Canada Posts: 1,294	Re: Stack and subroutine calls The MK14 saves P3+1 when user program returns to the monitor, the monitor adds one. As the return to the monitor uses XPPC P3 this is actually PC+1. The user program P3 is known and constant, this is the entry point to the monitor, if not correct then the user program could not return to the monitor. If Go is pressed the monitor subtracts one from the saved P3 and then uses XPPC P3 to execute user program. This XPPC P3 is followed by a jump to the monitor entry point. I think Kitbug is the same as the MK14 monitor. The MK14 has an add on circuit using a counter to implement single step debug using sense A as an interupt. There is a halt instruction in the monitor and the halt status on the data bus during NADS resets the counter, then the interupt is enabled before the XPPC P3, the counter then interupts the user program during execution of the first instruction and returns to the monitor. In my multiprocessor I use this halt instruction to free the next processor from reset, while the first processor continues the user program. The processor released from reset then starts running the monitor. The LCDS 32 byte prom seems similar to memory paging used on CPM systems for the boot prom, which is then switched out to give full 64k ram. I’d be interested in seeing the LCDS schematic to see how they do that.

22nd Apr 2023, 6:59 pm	#31
Michael Haardt Tetrode Join Date: May 2021 Location: Titz, Germany. Posts: 72	Re: Stack and subroutine calls The LCDS schematics and manual are here: http://www.bitsavers.org/components/national/scmp/ It looks as if the debug switch sets a flipflop that switches the address bus multiplexers from the CPU address bus to a clock triggered counter, so the CPU executes instructions from a different address than its PC. It is interesting that they recognized the lack of any exception or software interrupt early on, but did not add that to the CPU.