• Please review our updated Terms and Rules here

Powertran Cortex

Dave,

Working on the CF Card disk driver. Am I correct in assuming that the mdex kernel only uses the first part of the device data block (dtmstr to dtsize8) and that the rest (dtdeva to dtrvrtry) is private to the driver? I.e. I need to keep the first bit intact as is, and I can discard the second half? Or is it different in either direction (1. mdex treats pointer as opaque ID and never looks at the data structure at all; 2. mdex needs the whole structure as-is)?

Paul
 
pnr said:
Dave,

Working on the CF Card disk driver. Am I correct in assuming that the mdex kernel only uses the first part of the device data block (dtmstr to dtsize8) and that the rest (dtdeva to dtrvrtry) is private to the driver? I.e. I need to keep the first bit intact as is, and I can discard the second half? Or is it different in either direction (1. mdex treats pointer as opaque ID and never looks at the data structure at all; 2. mdex needs the whole structure as-is)?

Paul
Click to expand...

Hi Paul,

I have to confess I'm not really sure. Looking at the driver source and memory dumps of MDEX using debug, unit table ut$fd1 runs from dtmstr to dtrvrtrv + 16 bytes and ut$fd2 runs from dtmstr to dtsize8 + 16 bytes. They are obviously declared as global but I'm not sure of how much of these tables are actually used by the kernel. But, I suspect you know all this...

I suppose I could run a modified version of the emulator and put traps in to see if/when these areas of memory are accessed?

Dave.
 
Let's not get overboard on this. A no-work-involved alternative is to simply keep the data blocks intact as-is. When it boots I can progressively prune stuff and see if it keeps working. As the data block structure isn't mentioned at all in the sysgen manual, I'm tempted to think it is not too critical.

Another route altogether may be to look at a few other drivers and see how much variation there is in these data blocks. On Jim's site I could not find alternative disk images for mdex sysgen. Anybody have an mdex sysgen disk for the M9900?

And perhaps too practical to be fun, we could ask John Walker; perhaps he still remembers how it works.

Paul
 
Herewith a first draft of the mdex CF Card driver. Cannot test it yet, because I still need to modify the breadboard with circuitry to map out the ROM and I still need to write a boot loader.

The design of the driver is a bit silly, with the CF Card sector first being transferred to a buffer in the driver, and then the first 128 bytes copied to the user area. A more evolved design would be to move data from the CF Card to the user area directly for the first 128 bytes and to read & discard the other 384 bytes.
 

Attachments

  • cfdisc.asm.txt
    16.7 KB · Views: 1
I've just completed the breadboard boot loader (attached). It looks for the FAT32 files MDEX_FD0.DSK and MDEX_FD1.DSK, leaving sector no.'s at location ff00-ff07. It then looks for the file BOOT$.SAV on MDEX_FD0.DSK. If found, it loads this file into memory and transfers control.

Mdex then comes up, prints its hello line and the dot command prompt. I can enter and edit on the command line, but the command DIR or DIRECT crashes it. Now, the ROM is still at 0-7FFF, so this is the most likely source of error. It could also be that the CF Card driver has bugs.

I've attached a zip with the terminal driver (kindly provided by Dave), the CF card driver, the config file and the boot loader. The first three assemble with the mdex assembler, the last one with my unix assembler. Unless the last bits prove unexpectedly hard, I'd say we're 80% there.

It will probably be a week or so before I find the time to update the breadboard hardware, but so far so good.

Paul
 

Attachments

  • breadboard_mdex.zip
    10.7 KB · Views: 1
pnr said:
Mdex then comes up, prints its hello line and the dot command prompt. I can enter and edit on the command line, but the command DIR or DIRECT crashes it. Now, the ROM is still at 0-7FFF, so this is the most likely source of error. It could also be that the CF Card driver has bugs.
Click to expand...

That's great progress Paul! As for lower memory, I'm pretty certain MDEX loads most of its programs at 0x0100 (DIR is part of SHELL$.OBJ) so without RAM there, that could be a problem!

I'd have to check, but I have a feeling that MDEX also uses most of 0x0000 - 0x00FF as a scratchpad/working area.

Anyway, you've done extremely well to get this far so quickly.

Dave.
 
I'm happy to report that MDEX now runs on Stuart's breadboard. It required a few tweaks to the code, but that was all. It sure is a lot of fun to see it work this way.

If anybody on this list would like to replicate my setup, just holler and I'll prepare ready built files for the boot loader and the disk images.

tms9995 said:
Anyway, you've done extremely well to get this far so quickly.
Click to expand...
Thanks for your kind words, but you overestimate what I had to do. If you look back at this thread you'll see that all I had to do was writing ~300 lines of new CF Card driver code, change two lines in the config file and rework my CF Card test code into a boot loader, also just a few lines. Had it been any more work, I would not even have begun.

In fact, the real heavy lifting had already been done by others: I've given the breadboard version of MDEX version number "SDJ 1.0" (was "CX 3.31") where SDJ is Stuart/Dave/Jim to reflect this observation.

By the way, I stumbled across the below site, which has a very similar project but starting from a Z80 and C/PM:
http://searle.hostei.com/grant/cpm/
Interestingly, he is using the CF Card in 8-bit IDE mode, which I had not realized was possible (it probably doesn't work with a spinning rust disk). It looks like the electrical interface is almost the same, although using different pins.

Stuart, I'd like to add an addtional boot option to the ROM, so that I can start MDEX without having to use EVMBUG to load the bootloader. Would you have instructions on how to build the ROM image?

Thanks in advance,

Paul
 
pnr said:
Interestingly, he is using the CF Card in 8-bit IDE mode, which I had not realized was possible (it probably doesn't work with a spinning rust disk).
Click to expand...

I believe it actually does. All the control registers for basic IDE disk operation are 8-bit. You only use one byte of the 16-bit data word though, but that is hardly a problem.

====

Excellent work Paul! Now you have MDEX running, can you actually do anything useful/interesting with it (showing my shameful ignorance of what MDEX actually does!).

If you PM me your e-mail address I'll mail over the files I used to build the ROM. Could you do an updated circuit diagram as well? No problem if it's just a scanned hand-drawn sketch - I can draw it up using ExpressPCB.

Stuart.
 
Stuart said:
You only use one byte of the 16-bit data word though, but that is hardly a problem.
Click to expand...
It is if you want to keep the FAT formatting intact and thus allow for easy swapping between a PC and the breadboard. Perhaps I'm over-estimating the value of this. It was news to me that 8-bit data words also work in IDE mode with CF Cards.

Stuart said:
Excellent work Paul! Now you have MDEX running, can you actually do anything useful/interesting with it?
Click to expand...
Well, leaving aside that anything on a breadboard with 35 year old components and software has entertainment value only....

MDEX ("Marinchip Disc Executive") is a simple, disk based OS -- I've learned in the past few months that "executive" once was jargon for something in between a "monitor" and an "OS". We might say "embedded OS" these days, were it not that those have become pretty complete OS's as of late. Think of it as CP/M with a somewhat simplistic file system. It comes with a nice suite of software, see:
http://www.powertrancortex.com/documentation.html

* line based editor
* full screen editor
* assembler
* linker
* debugger/monitor
* disk utility
* basic interpreter (MS Basic like)
* basic compiler ('QBASIC', clone of CBASIC on CP/M)
* forth system
* pascal compiler (Brinch Hansen's sequential pascal)
* SPL compiler ("system programming language", think PL/M)
* word processor (a work-alike to CTSS's RUNOFF, also ancestor to nroff on Unix)
* spell checker
* meta compiler generator (see http://en.wikipedia.org/wiki/META_II; via CTSS and Multics, Meta became the ancestor to yacc, I believe)

From MDEX there is an upgrade path to NOS (Network Operating System). NOS is multiuser/process and has a better file system, not sure whether there is any beef to the 'network' moniker. It seems that MPE did a NOS version called NOS/TX that could run some DX10 binaries. Dave can perhaps tell you more.
 
So when you say that MDEX is running, does it run that suite of software, with load/save file capability? Or does it need more work to get that far?
 
Stuart said:
So when you say that MDEX is running, does it run that suite of software, with load/save file capability? Or does it need more work to get that far?
Click to expand...

I have not tried everything yet, but the assembler, linker and basic interpreter are confirmed working, including load/save capability. I would expect all other stuff to work out-of-the-box as well, just have not tried it yet.

The possible exception is the full screen editor, which MPE modified for use with a 9918/etc. chip. The original worked on terminals, not sure an ANSI/VT100 config file exists, but that seems as simple as defining a handful of escape sequences.
 
You guys have been busy.
Not helped by the fact the forum had stopped emailing me notifications again so the last messages I had seen were Stuarts April fool.
I too would be interested in updated circuit diagrams.
I spent quite a while doing schematics for a TMS99105 based system but it's suffered from feature creep and probably now needs a pcb the size of a Cortex.
I think i'll revamp it and stick with what I can get on a EBUS card, then everything else can go on extra EBUS boards.

Stuart, did you have the Cortex basic running on you 99105 board ?

Jim
 
Well I tip my hat to you again for getting all that going. ;-) Does load/save work with a FAT file format also, so one could transfer the files on a PC?
 
Stuart said:
Does load/save work with a FAT file format also, so one could transfer the files on a PC?
Click to expand...
Yes and no. At the MDEX level files are saved to disk "1" or "2". At the FAT level these are disk images, MDEX_FD0.DSK and MDEX_FD1.DSK. You can move files to and from those images using the tool I attached to post #700 a few days ago (a minor enhancement on code developed by Dave).

Now that one needs a tool at the PC level anyway, the advantage of having a FAT file system perhaps is a bit futile.

Paul
 
pnr said:
The possible exception is the full screen editor, which MPE modified for use with a 9918/etc. chip. The original worked on terminals, not sure an ANSI/VT100 config file exists, but that seems as simple as defining a handful of escape sequences.
Click to expand...

I have the original WINDOW code somewhere. As you say, it was setup to work with a VT100. I will try to dig it out...

Dave.
 
Stuart said:
Could you do an updated circuit diagram as well? No problem if it's just a scanned hand-drawn sketch - I can draw it up using ExpressPCB.
Click to expand...

Herewith the schematic, hope you can make out what I scribbled on the prints. Note that the inverters are LS14 (schmitt-trigger), not regular LS04; this is mostly relevant for the power-on reset circuit (and it might help sharpen up some signals).

Not sure how you would deal with the USB bridge (many makes, all different pin-outs) and the USB break-out board (out of production now) in a formal schematic for rebuilders.

The scan is too big to attach to the forum, so it will be available for download here for a limited time:
https://www.wetransfer.com/download...0f463cd1ec0bbe2c4f6083f620140605203701/e57442

Jim, Stuart, please advise when received in good order.
 
You must log in or register to reply here.
Back
Top