Commander X16

28 minutes ago, Anshul2 said:

Hello All,



I wanted to ask : is assembly language and monitor covered in the x16 manual?

Use of the monitor should be included, but a general assembly language reference and tutorial is really out of scope. There are plenty of resources out there for that, from 40 year old books to active websites.

9 hours ago, Fnord42 said:

That doesn't sound too bad - so the CPU could for example instruct an expansion card to write data directly to a specified memory area without having to squeeze everything through the 32 bytes of dedicated ram

It's not really RAM - it's I/O space. The system is set up so that when addresses within that 32 byte range are selected on the address bus, none of the internal memory chips respond. Instead, an expansion device is expected to set data on the data bus. 

So if you were going to use DMA to pre-load the system, the CPU would have to set one of those 32 addresses to particular value. The expansion device would be looking for that value at that address, then it would assert the DMA pin, and the CPU would shut down. Then the expansion device owns the bus while it does its thing. 

That thing can be: populating memory on the Commander, reading from the Commander memory, or even accessing the Commander's I/O devices (including VERA). So, as Bruce suggested, if you had an external processor on that bus, you could even take over the system completely and run it with something like a Z80 or 65816. 

This is how the CMD super CPU worked, as well as the CP/M cartridge and the 1750 Ram Expansion Unit. 

However... this requires a "smart" expansion cartridge, which doesn't make as much sense for simply distributing games or software. You'd be adding significantly to the cost to build a CPU onto the cart when all you really need is a PRG file that can be loaded from SD.

9 hours ago, Fnord42 said:

Missing autostart capabilities are probably not much of an issue, if that can be done via sd card. I hope it will be possible to run multiple autostart programs in a row, so I can load the drivers for my expansion cards and still autostart my boot menu system or favorite game or whatever

If I recall, The way Lorin described it was that the startup script would be a bit like a DOS batch file. It would contain a series of BASIC statements that would be executed from a buffer. 

So a menu program would not actually BE the startup script. It would be called FROM the startup script, which might look something like this:

	POKE 0,1:LOAD "SERIALDRIVER.PRG",8,1
	POKE 2,2
	POKE 0,1:SYS $C000
	RUN
	LOAD "MENU.PRG"
	RUN
	

In this example, you'd be loading a resident routine into bank 1, setting a configuration variable (POKE 2,2) to tell the program which expansion port to use, and then starting the driver (SYS $C000). 

After that, the startup script would load the menu program into BASIC memory and launch it normally.

Awesome, thank you for the explanation!

I understand that a "dumb" ROM cartridge would make little sense here, but I was thinking about a "smart" expansion card anyway - for example something that can be used more or less like a disk drive by the X16, but also acts as an FTP server to the outside world, so I can easily transfer files without having to move the sd card all the time.

2 hours ago, Fnord42 said:

Awesome, thank you for the explanation!



I understand that a "dumb" ROM cartridge would make little sense here, but I was thinking about a "smart" expansion card anyway - for example something that can be used more or less like a disk drive by the X16, but also acts as an FTP server to the outside world, so I can easily transfer files without having to move the sd card all the time.

That makes sense, and it's a really good idea. The 1541 Ultimate allows you to FTP files in while the system is running, and that's very convenient. 

However, what I'd probably do is, rather than make the device a disk drive, have it access the SD card through the system bus. Once you've grabbed the DMA pin, you can access the SD card just like the CPU, so if you were to open a file and push your data over to SD, there are zero drivers needed on the Commander. Everything would be self-contained in your network interface. 

 

 

4 hours ago, TomXP411 said:

... That thing can be: populating memory on the Commander, reading from the Commander memory, or even accessing the Commander's I/O devices (including VERA). So, as Bruce suggested, if you had an external processor on that bus, you could even take over the system completely and run it with something like a Z80 or 65816. 



This is how the CMD super CPU worked, as well as the CP/M cartridge and the 1750 Ram Expansion Unit. 



However... this requires a "smart" expansion cartridge, which doesn't make as much sense for simply distributing games or software. You'd be adding significantly to the cost to build a CPU onto the cart when all you really need is a PRG file that can be loaded from SD. ...

Unless, a la some Super Nintendo Entertainment System games, the game required special hardware to run ... and then really the game on the card is actually a teaser, because unlike the SNES carts, you could keep the card in the system and run any other games that required that hardware from the SD card.

Of course, after the overhead of having a board at all, there are different tiers of cost, which go with different levels of performance. If you have a 20MHz capable AVR8 running on a phase lock loop to double the CX16 system clock, you are going to have pretty cheap DMA, but it's going to be one byte every two cycles at best ... best case would probably be a Vera data port since it's a stable write target address ... maybe one byte every three cycles to write from AVR flash ROM to system RAM, one byte transferred every four or five cycles for page-alignmed inter-memory moves, maybe one byte every five or six cycles for arbitrary memory to memory moves. But it would be running on a program in the AVR, so it would know about the high ram banks, and so it could, for instance, grab and store the current High RAM bank when doing a read from or write to a Low RAM buffer, and then restore the original High RAM bank value when it is done.

Have an eZ80 running at 50MHz, with both the z80 opcodes and new opcodes running single cycle, with enough GPIO to run the DMA straight out of it's own I/O pins without needing to multiple address and data, you could well have a single cycle DMA for all but the most intricate cases, like blitting. THAT would be your "DOOM on the CX16" board, but it wouldn't really be DOOM on the CX16, it would be DOOM on the ez80 using the CX16 as a collection of I/O interfaces.

Still, the ez80 can act as an internet protocol bridge all on its own, so the combo I/O / DMA / Video Accelerator functions might entice a certain segment of the CX16 audience. After exploring that, it's all a bit too high frequency for my level of ambition ... I'm much more at the "bare bones budget 16MHz CP/M UserPort box" as a level of aspiration that is a stretch for me, but may or may not be within my grasp ... but if the "Maker Lisp" guy can be talked to, maybe he would do a stripped down version of his board that relies on the CX16 for I/O.

 

On 9/11/2020 at 8:06 PM, TomXP411 said:

...what I'd probably do is ... have [an expansion card] access the SD card through the system bus. Once you've grabbed the DMA pin, you can access the SD card just like the CPU, so if you were to open a file and push your data over to SD, there are zero drivers needed on the Commander. Everything would be self-contained in your network interface. 

That sounds brilliant.  A card that uses the internal SD card for a tiny NAS.