• Please review our updated Terms and Rules here

Powertran Cortex

Have a look at this:
http://1587660.websites.xs4all.nl/cgi-bin/9995/doc/tip/doc/old-as.pdf
It is for Ritchie's pdp11 assembler, but Miller's assembler is a work alike. Some differences though: // to introduce a comment, numbers follow C syntax (decimal by default), .if not implemented, etc. I will use this text as the base for my to-be-done 'as99' documentation.

I've just commited the changes to 'cc99' to make it work with relative paths. I'm adding standard libraries, but that is work in progress. So that you don't get stuck, I've temporarily added stub libraries to the repo. Alternatively, you could just replace 'cc.c' and leave the rest the same. Let me know if it works for you.

Cleaning up the Makefiles is next.

Paul

Assembler guide is very helpful. Thanks for that.

As I'm back to work for the next few days, time is limited so I think I'm happy to just back and let the 'dust settle' with the current phase of updates you are implementing. No point in playing catch-up each day.

Of course if there's something specific you'd like me to try, let me know.

Thanks,

Dave.
 
Just ported to the Cortex the Elite April Fool teaser I put together for the TI-99/4A. Cassette image here if you want a peek: [http://www.avjd51.dsl.pipex.com/powertran_cortex/games/elite_april_fool_cortex.zip]. Load by entering the MONitor and using the L command. Leave the IDT field blank when prompted. The game should load at >6200 and auto-run. Tested on Dave's WinCortex 2.0, but not on the real hardware.

Stuart.
 
Dave, is the Cassette menu for WinCortex 2.0 documented anywhere? [Play] and [Record Image] I've worked out, but not sure what [Record Raw] and [Overwrite Mode] are for?

Also, when [Play]ing an image, does the emulator check the header checksum before 'playing' it? From what I can see of the Cortex code, it should display 'Found""' for a program even if the header checksum is wrong, but the emulator just seems to ignore a [Play] command if the header checksum is wrong.

Stuart.
 
Dave, is the Cassette menu for WinCortex 2.0 documented anywhere? [Play] and [Record Image] I've worked out, but not sure what [Record Raw] and [Overwrite Mode] are for?

Also, when [Play]ing an image, does the emulator check the header checksum before 'playing' it? From what I can see of the Cortex code, it should display 'Found""' for a program even if the header checksum is wrong, but the emulator just seems to ignore a [Play] command if the header checksum is wrong.

Stuart.

Hi Stuart,

A manual for the emulator is long overdue. I started to write one last October but haven't got back to it yet... I need someone who excels at writing technical manuals ;)

Here are some notes on the Cassette Functions:

Two modes are available, Image and Raw. In Raw Mode, the 'cassette recorder' will record/play the cassette's TMS9902 data stream without any further processing. Image Mode is for program images where the 'cassette recorder' processes the data stream to produce .cas files that are compatible with the PC Comms Utility etc. Image files are 'concise' in that the preamble and other padding bytes are removed.

When a cassette image is 'played' back, the 'cassette recorder' detects whether a valid cassette header is in the file. If one is found, then the playback is treated as an Image, else Raw Mode is assumed.

Overwrite Mode provides the ability to automatically overwrite existing .cas files without being prompted.


To save a program from BASIC:

1) Cassette->Record Image (F6) and choose filename. 'Cassette Recorder' is now ready.
2) SAVE"" or SAVE"MYPROG"
3) Choose Auto-Run as required.
4) Press Y for cassette ready.
5) Image is recorded to file.
6) 'Cassette Recorder' can be aborted using Cassette->Abort Image Record or it will time-out after a minute if no SAVE is performed.


To save a machine code program (or data block) from MONITOR:

1) Cassette->Record Image (F6) and choose filename. 'Cassette Recorder' is now ready.
2) D SSSS EEEE AAAA where SSSS is the start address, EEEE is the end address and AAAA is the optional auto-run address.
3) Enter optional program name for IDT
4) Choose Auto-Run as required.
5) Press Y for cassette ready.
6) Image is recorded to file.
7) 'Cassette Recorder' can be aborted using Cassette->Abort Image Record or it will time-out after a minute if no SAVE is performed.


To load a BASIC program:

1) LOAD"" or LOAD"MYPROG"
2) Press Y for cassette ready.
3) Cassette->Play...(F5) and choose filename to load.
4) Image is 'played' and program is loaded.


To load a machine code program (or data block) from MONITOR:

1) L IDT= leave blank for no filename or use MYPROG as required.
2) Press Y for cassette ready.
3) Cassette->Play...(F5) and choose filename to load.
4) Image is 'played' and program/data is loaded.


RAW Recording:

1) Cassette->Record Raw...(F7) and choose filename. 'Cassette Recorder' is now in RAW Record mode.
2) In BASIC, UNIT 3 to turn on character output to the cassette device.
3) LIST program is LISTed to the cassette image.
4) Note: Any data written to the cassette device will be recorded, so a machine code could be written to output bytes etc.
5) Cassette->Stop Raw Record when logging to cassette device is no longer required.


RAW Playback:

1) In BASIC, BAUD 3,9600 to enable input from cassette device (baud rate is arbitrary).
2) Cassette->Play...(F5) and choose filename of RAW image.
3) RAW image is played back into the cassette device

Dave.

PS: Raw Mode was implemented just for you!
 
Last edited:
Just ported to the Cortex the Elite April Fool teaser I put together for the TI-99/4A. Cassette image here if you want a peek: [http://www.avjd51.dsl.pipex.com/powertran_cortex/games/elite_april_fool_cortex.zip]. Load by entering the MONitor and using the L command. Leave the IDT field blank when prompted. The game should load at >6200 and auto-run. Tested on Dave's WinCortex 2.0, but not on the real hardware.

Stuart.

Hi Stuart,

I loaded the program on the emulator and it runs until you press a key, upon which it aborts with "Error:Fail Lo Pro 2014" in red. I tried it on the Cortex and it does the same...

Dave.
 
Hi Stuart,

I loaded the program on the emulator and it runs until you press a key, upon which it aborts with "Error:Fail Lo Pro 2014" in red. I tried it on the Cortex and it does the same...

Dave.

Exactly. As I said, an April Fool teaser. ;-) "Fail Lo Pro" being an anagram of ...? Done in response to some people on one of the TI-99/4A forums who had been on about how nice it would be to have Elite running on the TI-99 - I got called a few rude names ... ;-) Ported to the Cortex just for the hell of it and the nice animation.
 
Exactly. As I said, an April Fool teaser. ;-) "Fail Lo Pro" being an anagram of ...? Done in response to some people on one of the TI-99/4A forums who had been on about how nice it would be to have Elite running on the TI-99 - I got called a few rude names ... ;-) Ported to the Cortex just for the hell of it and the nice animation.

I did wonder if I was setting myself up... Nicely done!
 
CF Card

CF Card

Finally finding some time for this project. I'm happy to report that the simple circuit to add a CF card to Stuart's breadboard (schematic posted a few weeks back) works. Who would have thought that a CF card can be almost directly hooked up to the CPU? Still running with an auto-wait-state, not sure if the timing will also work with zero wait states (min. specified width for /wr is 150ns, with zero wait states the 9995 @ 3 Mhz does 133ns?).

Have only done cursory testing. The 8 bit mode works, and reading sector 0 in memory mode indeed produces the MBR for a FAT32 drive (I'm using a cheapo no name 4GB card).

Paul
 
Have only done cursory testing. The 8 bit mode works, and reading sector 0 in memory mode indeed produces the MBR for a FAT32 drive (I'm using a cheapo no name 4GB card).

Done some further work and it works well. When a file is stored on the CF card on a PC, the breadboard can read and echo it to the terminal. This involves a very minimalistic implementation of a FAT32 reader: read the MBR and scan the partition table, read the partition boot block, read & scan the root directory, read & echo the file. My thinking is that I can store an entire xinu or unix v6 file system in an unfragmented FAT32 file of say 2MB in size and make it easy to transfer stuff between breadboard unix and a PC.

Given routines to read & write sectors, how hard would it be to:
1. give Stuart's Cortex Basic port load/save functionality?
2. port Cortex' CDOS?

I guess it might be possible to port MDEX as well, as the disk driver is open source on the sysgen disk.

Paul
 
I've got Cortex BASIC load/save to a CF on my TM990, so that should be easy to port across if you want it. I've got a basic disk OS that supports load/save/dir/format using a similar disk format to the TI-99/4A floppies, then I've added *extended commands to Cortex BASIC to load/save programs by making calls into the disk OS.
 
I've got Cortex BASIC load/save to a CF on my TM990, so that should be easy to port across if you want it. I've got a basic disk OS that supports load/save/dir/format using a similar disk format to the TI-99/4A floppies, then I've added *extended commands to Cortex BASIC to load/save programs by making calls into the disk OS.

That sounds promising, but I'm confused. If I understand correctly, after reset Cortex Basic only has a BOOT command that can read a boot loader from track 0 of a floppy. In the case of CDOS its core loads itself into memory between 0x6000 and 0x8000 and it patches Cortex Basic to have new LOAD and SAVE commands; it looks for a file SYSTEM$ on disk and loads this somewhere. SYSTEM$ patches Cortex Basic with OPEN/CLOSE/GET/PUT commands. I have not found sources for CDOS.

It sounds like you have done your own CFCard DOS using raw access (i.e. not building on top of FAT); how does it load itself, or is it simply in ROM? Also sounds like this DOS does not patch Cortex Basic at all. How do the *extended commands work, the documentation is silent on that, other than that it seems to require the memory mapper and extended memory (could not find the relevant routine in the source listing, at least not at first glance). At least, I think the breadboard would need some way to page out the ROM even just for space reasons alone.

I'n not sure I will do any porting, but I would be really grateful if you could elaborate a bit.
 
So my TM990 boots to the TIBUG monitor, which is an earlier version of EVMBUG used on the breadboard. I then have a DOS which sits in write-protected battery-backed RAM - but could equally be in (EP)ROM. The DOS has a simple command line interface like EVMBUG. To save a (machine code) program it prompts for save start address, save end address then file name and optional file description. To load a (machine code) program it prompts for load address then file name. Cortex BASIC I've previously downloaded then saved the memory image to CF, and I can load it again as needed to run from RAM.

The *extended command handler on the Cortex steps through extended memory (so needs the memory mapper as you say) looking for a header block for the extended command. But I've modified the copy for my TM990 so the header blocks for the load/save/dir/delete commands are in the code. Saving a file in BASIC calculates the save start and end addresses needed, then passes these to the DOS which then prompts for the file name, saves the block of memory, then returns to BASIC. Load works in a similar way. So BASIC isn't 'patched' as such by loading a DOS, I've just modified the BASIC source code to work with the DOS already available. The DOS is 3870 bytes and needs ~1.5K RAM for buffers and so on.

DOS commands are:
-- Read/display the CF identity information
-- Show CF interface status
-- Spin down/spin up - for the simple pleasure of being able spin a hard drive down and back up ;-)
-- show sector data in hex
-- fill a sector
-- save memory block
-- load memory block
-- load memory block and execute from specified address
-- display directory
-- rename file
-- edit description saved with each file
-- delete file
-- format disk
-- rename disk
 
Stuart, thank you for that explanation, much clearer now. I think I will pass on porting that. My motivation was to take the breadboard experience closer to the cortex experience for casual builders of the breadboard (all five of them :) ) and that would not be achieved. Moreover, I would have to get into the Cortex basic source, the file format and the source of your OS, and that is perhaps a bit much for now. Still, I very much appreciate your explanation.

Perhaps I should look at MDEX for an easier way to achieve something similar. I had a look at system generation, and at first glance it would seem to be not all that hard. The disk driver has only three api calls (init, read, write) and the terminal driver seems to have the 9902 code intact as the secondary device. The on disk format of the file system seems to be dead simple (see newsletter #21). I would appreciate any and all suggestions from the MDEX experts.

Is there already an open source PC tool to create MDEX file systems and add files to it?

Paul
 
and the terminal driver seems to have the 9902 code intact as the secondary device.
Attached a first draft of the ported terminal driver.
 

Attachments

  • term.txt
    11.2 KB · Views: 1
Perhaps I should look at MDEX for an easier way to achieve something similar. I had a look at system generation, and at first glance it would seem to be not all that hard. The disk driver has only three api calls (init, read, write) and the terminal driver seems to have the 9902 code intact as the secondary device. The on disk format of the file system seems to be dead simple (see newsletter #21). I would appreciate any and all suggestions from the MDEX experts.

Is there already an open source PC tool to create MDEX file systems and add files to it?

Paul

Hi Paul,

I still haven't tested the cc99/Cortex mods you did for me. Sorry! (It's on the list).

I'm pretty familiar with MDEX, so any help you need please ask. You have probably already read it, but I did a README on the "MDEXx0 Sysgen Release.dsk" that concisely (I hope) explains the Sysgen process. If not, I'd be happy to try and clarify things for you.

The MDEX Disk Utility I wrote is useful for extracting MDEX files from a disk image but I didn't create anything to put things back in the other direction. You can have to source if it would save you the time of developing your own algorithms (the interlacing with double density disks takes a little figuring out).

Dave.
 
Thanks for the offer of help. I would appreciate the source to the mdex disk extraction routines, to add create and write capabilities. Also would appreciate review of the draft driver(s).

Four questions on my mind today:
- the mdex core seems to have 8" metrics hard coded (single sided, 26 sectors, 77 tracks, 128 bytes per sector), but also seems to accept disks with >77 (virtual) tracks. How does it know the disk capacity? Can I create a 1MB virtual disk and will that work? Or am I limited to 640KB?
- the init routines store pointers to the device data block in locations >00fe, >00fc and >00fa for the console, fd0 and fd1 respectively. What is the significance of that, how does the mdex core use those pointers?
- what is the meaning of the the console 'flashit' API routine? It flashes a Cortex led, but when is that used? What does this API do on an M9900 Marinchip system?
- the console has an API consisting of 6 function calls, the disk has a single API called with 3 function codes. Just inconsistent design or any signficance to that?

My current line of thinking is to map fd0 and fd1 to two (unfragmented) files on the cf card FAT file system, of say 1MB each. fd0 could then hold all available mdex binaries and fd1 would be a work disk. Probably doing a simple linear map of sectors is the easiest.

For the initial system generation I would use your Cortex emulator. Once I have a new kernel generated, it should be able to self host. It will be interesting to compare LSX Unix and MDEX, as both are about the same size kernel (~12KB) and roughly contemporaneous ('76 versus '78 ).

Thanks in advance for any suggestions.

Paul

EDIT:
I can partially answer my own questions. I've looked at the mdex.rel file and at its REF/DEF's:
Code:
	REF	CRTCON		config
	REF	DBGROM		config
	REF	DIRSEC		config
	REF	DIRTRA		config
	REF	DSKSIZ		config
	REF	STDWS		config
	REF	SYSVER		config
	REF	TCRDLY		config

	REF	TREADC		term dev
	REF	TRESET		term dev
	REF	TRSTAT		term dev
	REF	TWRITE		term dev
	REF	TWSTAT		term dev

	REF	PIOPSF		disk dev
	REF	UT$FD1		disk dev
	REF	UT$FD2		disk dev
	REF	DSK$DF		disk dev

	REF	PIOPRT		print dev
	REF	UT$PR1		print dev

	DEF	INTCHK
The first 8 REF's are DEF'ined in the config.asm file, the others in the various device drivers. Findings:
1. The 'flashit' routine does not get REF'ed, so it is not used by mdex -- probably just something that MPE needed during development. We can forget about it.
2. The DSKSIZ config parameter specifies the number of sectors (26*77 in the original, 16*80 for the Cortex). Probably can be set much higher.
3. The device data blocks UT$FD1 and UT$FD2 also contain a sector/track count; probably should be set matching DSKSIZ
 
Last edited:
Hi Paul,

I was in the process of answering your questions when I noticed you'd beat me to it!

flashit just flashes the front panel LED when MDEX has finished loading. As you say, probably something MPE did to know it was running whilst they were developing the TMS9929 drivers etc.

The table of pointers to the device drivers was something MPE did to allow us to modify simple things without the use of the System Generation Kit, which was 495 British Pounds (no idea how I get up the proper symbol as I type this!). It just enabled us to locate the tables easily.

As you discovered, the disk capacity is defined in config.asm. I have no idea how high you can take it....

Dave.
 
- what is the meaning of the the console 'flashit' API routine? It flashes a Cortex led, but when is that used? What does this API do on an M9900 Marinchip system?

1. The 'flashit' routine does not get REF'ed, so it is not used by mdex -- probably just something that MPE needed during development. We can forget about it.

Interesting! I always thought the flashit* routine got called once at the end of the MDEX boot. But, you're right - it's not part of MDEX. So I did a little digging and it's actually part of the MDEX Loader. It can be found on "MDEX Boot Loader Source Release.dsk".
 
Thanks for the offer of help. I would appreciate the source to the mdex disk extraction routines, to add create and write capabilities. Also would appreciate review of the draft driver(s).


Attached is the main chunk of code for the MDEX Disk Utility. The BlockToOffset function is what converts MDEX Block Number to a linear disk address.

Dave.
 

Attachments

  • main.cpp.txt
    15.9 KB · Views: 1
Attached is the main chunk of code for the MDEX Disk Utility
Thanks a zillion. Attached a reworked command line version that can create/add/remove/list/etc. disk images. There are two create options, -c and -f. The former creates a standard 640KB Cortex mdex disk image, the latter creates an image to place on a CF Card. I've chosen to use a mimic of DSDD 8" drive, this gives a capacity of about a megabyte. To keep things simple, each logical 128 byte mdex sector maps one-to-one to the first 128 bytes of a 512 byte CF Card sector. This wastes 75%, but simplifies the driver enormously (and even at 4MB, it is only 0.1% of a 4GB CF card).

To get a listing of an image use the -l option:
Code:
$> mdexdsk -l imagefile.dsk

To add a file to the image, use the -a option:
Code:
$> mdexdsk -a imagefile.dsk driver.asm

I've used this tool to transfer the new terminal driver to a sysgen disk and using the Cortex emulator it seems to assemble (there is a mysterious relocation error during assembly, but output code is still generated) and link. Now on to the CF card driver and extending the breadboard with a way to map out the rom.

Any and all help is welcome.

Paul
 

Attachments

  • mdexdsk.c.txt
    18.6 KB · Views: 1
Back
Top