Thanks to Garth Wilson, I'm on my way to getting POC V2 running.

Garth took care of soldering the two static RAMs and the Ø2 clock flip-flop—which devices are SMT—to the PCB, and did a very nice job of it. The balance of the components are through-hole, which, despite only having vision in one eye, I should be able assemble. With any luck, I'll soon be ready to put power to this thing to see if it goes or blows.

Some pics follow.


Above are the two SRAMs (512KB each) and a 74ABT74 flip-flop, the former in SOJ36 and the latter in SOIC14.


Above is a close-up of one of the SRAMs so you can see Garth's handiwork.


Above is a close-up of the flip-flop. These SOIC14 packages sure don't take up much room. For some reason, my camera kept trying to focus on the silk screening in the foreground, making the subject (the flop) a bit blurry.


Above is how I set up PCBs for assembly. It's nothing fancy—I've been using this crude method for some 40 years. I put rubber caps on the long ends of the standoffs so the assembly doesn't slide around on the bench whilst poking it with the soldering iron. The caps are 8mm vacuum caps commonly used on automobile engines.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That's amazing news! "Goes or blows"... I'll have to remember that one!

Garth did a terrific job of the SMT soldering. Was that done by hand?



I'm embarrassed to admit I'd never have thought of doing that. That would have been a very handy approach when I was soldering up my MAXI09 board (25cm x 20cm or so). Oh well, I'll do that next time.

Can't wait to hear how you get on. I'm sure it will be a "Go" and not a "Blow".

_________________
8 bit fun and games: https://www.aslak.net/

It's actually an old drag racing term from the 1950s, when the Ford flathead V-8 was in widespread use. The flathead had only three main bearings, unlike the five used in later V8s, and if souped up too much would sometimes self-destruct when the driver wound up the engine and popped the clutch. In other words, the engine would blow and the car wouldn't go.


Yes it was.


I'm planning on doing the assembly and preliminary testing on Sunday. If it blows I'll try to get a picture of the mushroom cloud.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Great team effort!

Here is the memory map for POC V2:

Code:

           +——————————————————————————+ $0FFFFF
           |                          |
           |                          |
           |                          |
           |  Extended RAM  (960 KB)  |
           |                          |
           |                          |
           |                          |
   +———————+——————————————————————————+ $010000
   |       |                          |
   | HIRAM |       HIROM (8 KB)       |
   |       |                          |
   +———————+——————————————————————————+ $00E000
           |      HMU (0.25 KB)       |
           +——————————————————————————+ $00DF00
           |                          |
           |   D-Block RAM (1.75 KB)  |
           |                          |
   +———————+——————————————————————————+ $00D800
   |       |                          |
   | IORAM |    I/O Devices (2 KB)    |
   |       |                          |
   +———————+——————————————————————————+ $00D000
   |       |                          |
   | LOROM |       LORAM (4 KB)       |
   |       |                          |
   +———————+——————————————————————————+ $00C000
           |                          |
           |     Base RAM (48 KB)     |
           |                          |
           +——————————————————————————+ $000000

At reset, ROM is mapped in at $00E000-$00FFFF and I/O is mapped in at $00D000-$00D7FF. Everything else except the hardware management unit (HMU) appears as RAM.

The HMU, which is a set of registers in the ATF1504AS CPLD, is defined as follows:

Code:

  HMU
Register   Address   Register Description   Type  Bit  Function
——————————————————————————————————————————————————————————————————————————————————————————
hmumcfg    $00DF00   Memory configuration:   R/W   0   0: I/O at $00D000-$00D7FF (default)
                                                       1: RAM at $00D000-$00D7FF
                                                   1   0: RAM at $00C000-$00CFFF (default)
                                                       1: ROM at $00C000-$00CFFF
                                                   2   0: ROM at $00E000-$00FFFF (default)
                                                       1: RAM at $00E000-$00FFFF
                                                   3   0: HIRAM write-enabled    (default)
                                                       1: HIRAM write-protected
——————————————————————————————————————————————————————————————————————————————————————————

At reset, the HMU will be initialized to %0000, establishing the default memory map (STZ HMUMCFG will default the map). Writing to ROM will "bleed through" to RAM at the same address. This behavior will be inhibited when writing to HIROM if HIRAM has been write-protected—a write to write-protected RAM will go into the bit bucket. The HMU itself is read/write and is always present in the memory map. The TRB and TSB instructions are handy for manipulating the HMU with minimal code. As I have maxed out usage of the CPLD's I/O pins, bits 4-7 are "don't cares" when writing. So an instruction such as:

Code:

         lda #%00000001
         trb hmumcfg           ;map in I/O hardware

will work as expected, as long as the secondary status register effects of TRB (and TSB) are of no interest.

I/O hardware is defined as follows:

Code:

———————————————————————————————————————————
$00D000   SC28C94 quad channel UART
$00D100   DS1511 real-time clock
$00D200   53CF94 SCSI controller registers
$00D300   53CF94 SCSI DMA data port
$00D400   53CF94 SCSI DMA request handshake
$00D500   unassigned
$00D600   unassigned
$00D700   unassigned
———————————————————————————————————————————

For initial testing purposes, I will be using the firmware written for POC V1.1, since POC V2's boot-time memory map will be functionally identical. The only change that I expect to have to make is to burn the firmware into the ROM at $1000 instead of $0000 so it appears at $00E000.

Once I know that the hardware is working as it should I will develop new firmware for the unit, which will take advantage of the more expansive memory map. ROM will be arranged as follows—addresses are relative to the ROM itself:

Code:

—————————————————————————————————————————————
$0000-$0FFF   machine language monitor   4 KB
$1000-$2FFF   BIOS & interrupt handlers  8 KB
—————————————————————————————————————————————

The new firmware's reset handler will use the MVN instruction to copy HIROM into HIRAM, after which HIRAM will be write-protected (see above HMU details) and HIROM will be mapped out. At that point, the BIOS and interrupt handlers will be running from RAM, thus avoiding the performance penalty of a ROM wait-state. I/O accesses will require one wait-state per read or write operation in order to support maximum MPU speed.

Here is a synopsis of the RAM usage I have planned:

Code:

                                                        Contiguous
 Address Range    Assignment                                 Bytes
——————————————————————————————————————————————————————————————————
$000000-$00007F   system direct page                           128
$000080-$0000FF   user-accessible direct page                  128
$000100-$00010F   system indirect jump vectors                  16
$000110-$00014F   logged SCSI devices table                     64
$000150-$00017F   system workspace                              48
$000180-$0001FF   bank $00 user-accessible workspace           128
$000200-$00027F   machine language monitor workspace           128
$000280-$00CFFF   bank $00 user-accessible workspace        52,608
$00D800-$00DBFF   TIA-232 I/O buffers (8 total)               1024
$00DC00-$00DEFF   65C816 hardware stack                        768
$010000-$0FFFFF   extended RAM user-accessible workspace   983,040
——————————————————————————————————————————————————————————————————

A firmware design issue I had to settle was how to make it possible for a program running anywhere in address space to access the BIOS API. With the 65C816, the choices are:

1. Function jump table. This is the method I am using in POC V1.1. The user program calls a BIOS function as a subroutine. In POC V2, the JSL (Jump to Subroutine Long) instruction would have to be used in place of JSR to make the BIOS reachable from anywhere in the address space—the BIOS function would have to exit with RTL (ReTurn Long) in order to return to the caller's bank. The API jump table would be a series of three byte entries starting with $4C (a JMP instruction) and ending with a 16 bit address, each one pointing to a different function in the BIOS.
   
   
2. Single entrance with index. In this method, the API is exposed at only one address, reached via JSL, as explained in #1 above. The caller passes an index to the API telling it which BIOS function to run, the index being passed in one of the MPU's registers or via the stack, the latter method being convenient with the 65C816. As an example of the latter, the following code would send the letter A out TIA-232 channel C:
   
   
   Code:
            lda #'A'              ;letter A
            pea #putchc           ;push API index to...
            jsl biosapi           ;write to TIA-232 channel C
   
   The API front end would retrieve the index from the stack, double it to turn it into a table index and then use it to select and run the target function. Execution of the function would be accomplished with JMP (APITAB,X) once .X has been loaded with the correct index, APITAB being a table of 16 bit addresses pointing to functions. A common API back end would clean up the stack to get rid of the API index before returning to the caller.
   
   
3. Software interrupt. In this method, the caller executes a BRK or COP instruction to call the BIOS function. An API index is either loaded into a register, pushed to the stack or used as a signature byte for the BRK or COP instruction. Any interrupt on the 65C816 automatically directs execution to bank $00, which is where the BIOS is located (in HIROM or HIRAM). If the API index is passed in a register or via the stack internal API processing is essentially like that described in #2 above. If the signature byte to the BRK or COP instruction is used as the API index a more complicated API front end will be required to fetch and process the index.
   
   On the 65C816, COP is the preferred instruction for this method, as BRK is often used for debugging purposes and thus would complicate software design. An example of how to send the letter A out TIA-232 channel C follows:
   
   
   Code:
            lda #'A'              ;letter A
            pea #putchc           ;push API index
            cop $00               ;write to TIA-232 channel C
   
   The API back end returns to the caller with an RTI instruction after performing whatever stack housekeeping is necessary.

Pros and cons, in method order:

1. This method has the highest execution speed and the least complicated API front and back ends.
   
   That said, the calling syntax (JSL <function>) is a four byte instruction that when paired with the matching RTL instruction, consumes 14 clock cycles total. Furthermore, each API jump table entry is a three byte JMP instruction, which means the table will consume quite a bit of ROM space if a significant number of API calls exist (POC V1.1 currently has 20 calls, resulting in a 60 byte jump table). Also, a copy of the API jump table definitions has to be INCLUDEd in the source code of any program that makes BIOS API calls. If the API jump table is edited to add new functions and the order of the table and/or its location in ROM is changed, all applications using BIOS calls will have to be reassembled.
   
   
2. This method has the advantage of not requiring that applications know anything about a jump table, since entrance into the BIOS is through a single fixed address, with the API index indicating which function is to be run. If a new function is added to the BIOS it can be assigned the next highest unused API index, with no effect on existing programs. Programs using the BIOS API must, of course, INCLUDE the API index table definitions during assembly. The internal function look-up table that directs execution consists only of 16 bit addresses, hence using less ROM space.
   
   As with #1, this method must use the slower-acting, four byte JSL instruction, paired with RTL, for a total of 14 clock cycles of immutable overhead. Also, the API front and back ends are more complicated than that of #1 due to the code needed to process the API index, that complexity also resulting in a performance penalty. The front and back end code size will partially offset the savings realized with the more succinct internal function look-up table.
   
   
3. As with #2, this method eliminates the need for applications to know anything about a jump table. In fact, applications need have no knowledge whatsoever of where the BIOS is located in address space, making it possible to make major changes to the BIOS internals with minimal effect on applications. The API calling method is more succinct than that used in #1 and #2, making applications that use a lot of BIOS API calls more compact. As with #2, adding a new function to the API will not affect older programs if the next highest unused index is assigned to the new function. A bonus of this method is the 65C816 automatically pushes the status register (SR) to the stack when any interrupt occurs, which is convenient for BIOS code that modifies SR prior to returning to the caller. An additional bonus is a software interrupt causes the 65C816 to assert the vector pull (VPB) output when the interrupt vector is fetched, which can be used to change the execution environment in some fashion.
   
   This method is slightly slower-executing than #2, due to the combined execution time of COP and RTI, a total of 15 clock cycles of immutable overhead. However, the API front and back ends are no more complicated than those of #2 (assuming the signature byte isn't used as the index), so the overall performance penalty is slight.

Incidentally, the calling syntax for methods 2 and 3 can be buried in friendly macros, such as PUTCHC 'A' to write the letter A to TIA-232 channel C. Can you guess which method I have chosen?

———————————————————————
Edit: I had the QUART and RTC backwards in the hardware assignments table.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Nice write-up!

I was about to suggest that the BRK/COP method has the disadvantage of not being able to signal results through the Carry flag (or indeed, N, Z or V flags) but of course that's not quite so: the OS would just need to tweak the stack-located P register before doing the RTI.

I would say there's something of a continuum between methods 1 and 2. You can have a relatively small number of call sites but with the more complex functions taking parameters. For an extreme case, see ioctl in a unix-like OS.

Hmm, the following excerpt seems to me to be a very powerful hint!

"a software interrupt causes the 65C816 to assert the vector pull (VPB) output when the interrupt vector is fetched, which can be used to change the execution environment in some fashion."

BTW, it strikes me as odd that the I/O area and the HMU area are separated by an islanded RAM area ("D-Block"). No big deal, but if it were my decision I'd find it slightly better to have that 1.75K of RAM contiguous with the main RAM area further down. And it's easily done: just swap the $800 of stuff you have at $00D000 with the $800 of stuff you have at $00D800.

Nice to see this project moving ahead!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Signaling results via a flag would be darn handy! If it happens often enough, the following tradeoff may be attractive:

• Every call to a BIOS function that doesn't return a flag would be a BRK, or COP. (Optionally you could add a NOP afterward if you wanted consistency with what I mention below.) The function exits the bios with just an RTI.
  
  
• Every call to a BIOS function that does return a flag would be a BRK (or COP) followed by a NOP. We pop the old flags using a PLP instruction, update P, then exit the bios using an RTL instruction. The gain here is quite substantial, as we've avoided the need to access the stack in order to tweak the P register. (The NOP gets skipped. Recall that RTS/RTL will increment the return address, unlike RTI.)

Just thinking out loud... Another way this could work is if, instead of NOP, the BRK were followed by CLC or similar. Do I need to explain? There'd be two possible return procedures, both very simple: either RTI, or PLP then RTL. If it's the former, a one-byte instruction following the BRK will get executed. If it's the latter, it won't.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks!


Manipulating the stack copy of SR is easy with the '816. LDA <offset>,S, etc.


There is a bit of continuum between the two. It comes down to speed versus less speed. So far, no BIOS function in POC V1.1 requires more than three 16 bit parameters, so they can be made available during an API call via the registers. For now, I expect POC V2's BIOS will be no more complex.


Due to an insufficient number of I/O pins on the ATF1504AS, I do not have VPB connected to it. So the above feature in itself wouldn't be a factor.

However, I did decide to use the software interrupt method, since I will be using the same method when I finally get a kernel written. POC V3 (assuming I live long enough to build it) will have much more in the way of logic resources, so I will account for VPB and /ABORT in that design. I'm working my way there in stages.


Actually, creation of that "island" was intentional. I wanted to keep I/O at $00D000 so I wouldn't have to change anything in POC V1.1's firmware, since it should be able to run V2 for proving that the hardware works. There are currently five I/O assignments and as all I/O pins on the CPLD are spoken for, there was no point in allocating the entire D-block to I/O, although I did leave $00D500-$00D7FF unassigned as a matter of program convenience. By default, if ROM or I/O is not in context at any given location RAM appears. Hence the island and its size.

That space will not go to waste. As noted in my write-up, the firmware that will be specific to POC V2 will allocate the first 1K of the island to the eight TIA-232 buffers (128 bytes each). The remaining 768 bytes will give the MPU stack a nice home, with the stack pointer initialized to $DEFF at reset. A lot of return addresses, stack frames and such can be jammed into 768 bytes.

Code and data will have over 52KB of uncommitted bank $00 RAM, plus 128 bytes of uncommitted direct page. Don't forget about the other 960KB of extended RAM, all of it available for code and data. Code can be run from anywhere, as the BIOS API will be reachable from anywhere. There is no reason to run code in bank $00, except for the BIOS, interrupt handlers and I/O primitives. When I finally get a small kernel written it too will run in bank $00 and its API will also be called via a software interrupt.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

This is an area of the BIOS design that I've mentally kicked around quite a bit. The first decision I made was to use COP to do BIOS API calls, thus allowing BRK to continue to be used for the usual debugging purposes—it's a convenient arrangement, since the two software interrupts are separately vectored, but otherwise function the same.

COP, like BRK, is followed with a signature byte, which is tempting to use as the API function index. However, fetching the signature is not a straightforward process. The signature's address has to be computed by getting the return address from the stack, decrementing it, and using the result as a pointer or index. The value of PB as it existed at the time of the interrupt has to be copied from the stack as well and written to DB, since there is no guarantee that DB was the same as PB at the time of the interrupt. Once that is done the signature can be fetched. However, DB has to then be restored to what it was before the signature was fetched. It's a fair amount of hoop-jumping to fetch one byte.

The other methods of passing the API index are loading it into a register or pushing it before executing COP. I'd prefer to keep all registers unencumbered so they can be used to pass parameters into function calls (for example, the API for issuing a command to a SCSI device requires one 8 bit and two 16 bit parameters). So the method I will use will be to push the index using PEA or PEI, depending on the code. Fetching the index off the stack is easy. Some stack housekeeping will be necessary before returning to the caller, but that too is easy with the '816.

What this means is a single API front end will take care of preserving registers, verifying that the API index is valid and then dispatching to the function code. Similarly, a single back end will take care of writing register return values to the stack, performing stack housekeeping and then reloading the registers and returning to the caller. I think the code will be less error-prone and more compact.

Of course, I'm always looking for anything that will make the code shrink and at the same time, go faster.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hmm. I don't disagree with any of that, but my post had to do with a non-stack-oriented way of returning altered flags to the caller.

That's alright -- the idea maybe isn't everyone's cup of tea. But some of you will find it interesting.

BDD remarked earlier that...... which is true. Compared with 'c02, stack accesses with the '816 are definitely easier.

However, what I suggested was a way (actually two ways) to omit the stack access and use an even shorter and faster method of returning altered flags -- so much faster that the one mentioned in the last paragraph doesn't even require touching A, X or Y! Let's say a bios routine needs to return a yes-no message, either "a" or "b," to the caller. For message "a" the routine exits using RTI, and a one-byte instruction located right after the BRK in the calling code will get executed. But for message "b" the bios routine would exit using PLP followed by RTL, which results in the one-byte instruction following the BRK getting skipped. So, for example, by using CLC or SEC as the conditionally-executed instruction after the BRK you can cause the "message" to end up in the carry flag! (Carry would have to be in a known state beforehand.) The other variation would allow multiple flags to be returned to the caller.

I'm not tryna do a hard sell, but heck --I thought the idea was kinda cool... ( ... so cool that somebody likely already thought of it before I did! ) But no need to pursue the thing here -- a separate thread would be better.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Well, you know I am always looking for ways to pound nails without having to swing the hammer too many times.

None of this is cast in concrete, as initial POC V2 testing will be with the V1.1 BIOS. After I leap the hurdle of getting the hardware running and have proved that my CPLD logic is correct (or not) I will focus on the new firmware and make the decisions on how to handle the API front and back ends.

Your ideas on how to propagate SR back to the caller without a lot bit twiddling on the stack copy should yield some performance gain. If you recall, I started a topic a while back on 65C816 programming trickery. That would be a good place to explore this some more, since it would be '816-specific and definitely a programming trick, one related to the "lie to the machine" philospohy.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

"Lying to the machine" is something I picked up from Don Lancaster (in the context of cheap video). I took the lesson to heart, and since then I've become utterly remorseless!

This little programming trick we're talking about today isn't exactly lying, but it does exploit foreknowledge of a predictable quirk in the victim's response. The same technique can be applied to humans -- people and CPU's are both susceptible to social engineering!

BTW if you replace RTL with RTS then the programming trick becomes usable on 6502 and 'C02 as well as '816.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

It's a nice little invention/discovery Jeff - I think it deserves a thread of its own. It might even prompt me to try to write something about possible implementation reasons behind why RTS and RTI treat the PC differently.

Okay, let's call it "programming by deception."

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!