Joined: Thu May 28, 2009 9:46 pm
Posts: 8505
Location: Midwestern USA
|
BigEd wrote: Hi BDD
is any of your firmware source available? If not, do you expect to publish it in the future?
Cheers
Ed
Ed, I posted the entire BIOS ROM listing on POC's website. Select Downloads and you'll see it. The file size is about 550KB (ASCII) and 11,700+ lines. This listing is ROM 0.8.1 and contains all planned features except one with which I'm still tinkering. Once that feature has been coded and debugged, the ROM will officially become version 1.0.0 and, barring the discovery of more bugs, will probably not receive further development. The next ROM will be for POC 2 when it gets built. Just about everything in POC V1's ROM will be transferable with little alteration.
Here's a synopsis of all the features of POC V1's ROM:
- 100 percent native 65C816 operation. Except for a few lines of code at the beginning of the reset routine, the 65C816 is run in native mode, using 16 bit operations where beneficial. I made extensive use of 816-specific instructions, especially in number processing.
- Buffered and interrupt-driven serial I/O. Port A is the console port and port B is the auxiliary port, presently used as a data link to my UNIX development box. Both ports can be run at up to 115.2 Kbps.
- Checkerboard memory sizing and testing. The tests include detailed scans of the zero page and stack areas before the POST display is enabled. Once POST is enabled the absolute memory count is displayed as testing progresses, just like on a "real" computer.
- Interrupt-driven SCSI support. The SCSI subsystem implements all useful SCSI-1 features and a few SCSI-2 features. I did not implement tagged queuing and disconnect/reconnect, due to insufficient ROM space.
- BIOS primitives jump table. The jump table, starting at $00E000, includes entry points for console and auxiliary port byte-at-a-time I/O, reading and writing the timekeeper, SCSI command execution, character string output to the console, reading or writing NVRAM, etc.
- Initial system load (ISL) capability. Following POST and SCSI enumeration, the BIOS will attempt to load the boot block from the boot device (SCSI ID $00) and execute master boot code, if present. Master boot will then attempt to load and execute a stage 1 boot loader that can ultimately start an operating system. There is also space in the boot block allocated to setting up a filesystem table (four filesystems maximum per disk). Master boot does not look at this table—that's the job of the stage 1 boot loader.
- Uptime counter, programmable delay timer and alarm. I did the uptime counter early on as part of the exercise to get the Dallas watchdog to generate jiffy IRQs—the UT counter proved that the watchdog was not merely sleeping in his house. The UT counter is also handy for gauging the stability of the system (longest uptime to date has been 73 days).
Originally, I created the alarm to deal with a potential "no IRQ" issue with the 53C94 controller, but I have since found it useful for other purposes. I experimented with several implementations before settling on the present version, which isn't necessarily the final version.
- NVRAM support. The Dallas watchdog has 256 bytes of NVRAM available for any use. I use it to store the primary and secondary boot device IDs, the time zone (the clock itself is set to UTC), default console and auxiliary port BPS, and some other data. There's a 16 bit checksum to verify that valid data exists. Due to a lack of space in the BIOS ROM, an external program has to be loaded and run to change NVRAM, or to set the date and time.
- Intelligent console support. I devised a macro language that can be embedded in any text string to execute console procedures, such as clearing the screen, addressing the cursor, and so forth. There are also commands to change display intensity, enable reverse video and draw box graphics, the latter which I put to work in displaying the POST screen's banner.
- Machine language monitor. The monitor was scratch-written to use the 65C816's native mode and 16 bit registers. Monitor features include:
- A - Assemble code.
- C - Compare memory areas.
- D - Disassemble code.
- F - Fill memory.
- G - Execute code.
- H - Search memory for pattern.
- J - Execute code as a subroutine.
- L - Load code (see below).
- M - Dump memory.
- R - Dump MPU registers.
- T - Copy memory to memory.
- V - Display ROM version.
- Z - Clear console screen.
- > - Change memory.
- ; - Change MPU registers.
- ! - Execute SCSI command. Commands include:
- F - Format unit.
- I - Reset SCSI subsystem.
- R - Read block(s) from unit.
- S - Read sense data from device.
- W - Write block(s) to unit.
- Ctrl-D - Soft-reset system, similar to a PC's three-finger salute.
The F and T commands are implemented with the '816's MVN (block copy) instruction, resulting in incredibly quick response. SCSI commands are entered as:
Code: !<cmd>
followed by whatever parameters are required. For example, to read from a SCSI device, one would enter:
Code: !r <ID> <LUN> <LBA> <NBLKS> <BUFFER>
where:
Code: <ID> SCSI device ID, $00-$07
<LUN> SCSI logical unit (usually zero on most devices)
<LBA> Logical block address, zero-based
<NBLKS> Number of blocks to read (512 bytes per block with disks and tapes, 2048 with CDs)
<BUFFER> Where the blocks will go
In addition to the above commands, the monitor has a built-in number conversion feature. Typing a number in binary, octal, decimal or hex will display that number in all four bases, e.g.:
Code: +49151
$BFFF
+49151
@00137777
%1011111111111111
All numbers are internally represented by 32 bit integers. Addresses and instruction operands may be entered as 8, 16 or 24 bit values in any base, although POC V1's architecture doesn't decode addresses beyond $00FFFF. Depending on the instruction, it is possible to assemble code with a 24 bit address, e.g.:
Code: LDA $123456,X
although the address' MSB ($12) will not result in access to RAM bank $12, since there is no bank other than $00. Also, since the '816 has dual-sized registers, an instruction such as:
Code: LDA #$8F04
is legitimate. Entering:
Code: LDA !#$21
will assemble as:
Code: A9 21 00 LDA #$0021
a feature referred to as "force long immediate" (FLIMM) in the ROM listing comments. Without the !, the instruction would be assembled as:
Code: A9 21 LDA #$21
This also works for the .X and .Y registers. Plus you can also do something like:
Code: BIT !#$21
which will assemble as:
Code: 89 21 00 BIT #$0021
Of course, you could also enter it as:
Code: BIT !#%100001
and get the same result. Hex is the default radix if no radix is entered.
The data loader (L) takes a Motorola S-record input stream from the auxiliary serial port, converts it to binary, checks for errors and writes to the appropriate location in memory. During the load a progress indicator is printed to the console and when done, the starting and ending addresses to which the load occurred are displayed. Normally, loading occurs to the address in each record, but can be changed for the entire load by entering a page offset, e.g.;
Code: L $04
The above would add $0400 to all load addresses, wrapping around if the resulting address exceeds $FFFF. The loader can process S0, S1, S5 and S9 records—the computer sending the S-record data must transmit <EOT> as the last character to terminate the process. The loader can deal with CRLF or LF line endings, making it compatible with S-record files created in either Linux/UNIX or DOS/Windows.
All of the above is crammed into an 8KB ROM space. There are only 81 bytes in the ROM that are unused.
By the way, any resemblance between this monitor's features and those of the Commodore 128's resident monitor wasn't coincidental. The C-128's monitor was well-designed (unusual for CBM—they must've purloined Jim Butterfield's SuperMon  ), and other than adding the SCSI commands and S-record loader, as well as extended addressing support, I didn't see any need for any functional improvement. The monitor's code is not a copy, however, as the '816 is sufficiently advanced over the 6502 to warrant starting with a blank canvas.
As published, the ROM listing can't be assembled unless edited to get rid of the stuff added by the assembler. However, before someone starts writing a sed script to do so, you should know that when the ROM reaches version 1.0.0, my next task will be to disassociate the machine language monitor from the rest of the ROM and make it available for anyone who wants it. As written, all source code is tailored to the Kowalski assembler, with extensive macro usage to adapt to the '816-specific instructions. To make it easier for someone to assemble the code outside of the Kowalski environment, I'll eventually generate a version that will be compliant to WDC's assembler syntax standards and as devoid of macros as possible._________________ x86? We ain't got no x86. We don't NEED no stinking x86!
Last edited by BigDumbDinosaur on Mon Aug 20, 2012 10:55 pm, edited 1 time in total.
|
|
Login
Register
FAQ
Search
)
