Jump to content
Anshul2

Is there a cartirdge port , user port, cassette port on the commander x-16?

Recommended Posts

The X16 will have a user port. However, cassettes won't be supported by the base design (at least for now). The system will read from SD cards (provided by the VERA's SPI controller) and floppy disks (using the Commodore IEC serial interface).

There aren't any cartridge slots, however, there will be 4 general-purpose expansion slots in favor of using expansion carts.

Share this post


Link to post
Share on other sites

So, the expansion ports are seperate from the user port?

Can an expansion card override ROM functions and/or make the CPU run code on power on? (In other words: can an expansion card provide its own drivers, without the need of an extra disk?)

Share this post


Link to post
Share on other sites
11 hours ago, Fnord42 said:

So, the expansion ports are seperate from the user port?

Can an expansion card override ROM functions and/or make the CPU run code on power on? (In other words: can an expansion card provide its own drivers, without the need of an extra disk?)

No, the RAM and ROM cannot be overridden by the expansion slots. The expansion slots get 32 bytes of dedicated address space, so that's not enough for a ROM. Instead, driver software should be loaded from SD in the autorun script. 

The "cartridge" slot is the SD card slot. User can swap out SD cards and reboot, and an SD card will have some sort of autorun mechanism. 

The User port is basically 14 GPIO lines, along with some interrupt driven control signals, which can be used for a printer, modem, or which can be arbitrary controlled for other devices.

 

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, TomXP411 said:

The User port is basically 14 GPIO lines, along with some interrupt driven control signals, which can be used for a printer, modem, or which can be arbitrary controlled for other devices.

I thought there were 16 GPIO lines driven by one of the VIA's?

Share this post


Link to post
Share on other sites
4 hours ago, StinkerB06 said:

I thought there were 16 GPIO lines driven by one of the VIA's?

Port B has pb0-pb5 specified, so I guess one can presume the system uses pb6 and pb7 of that VIA. If they are inputs, then writing %00xxxxxx into Port B output GPIO wouldn't interfere with their system uses - though unless they document them as always input, best to preserve their setting in code setting the port b data  direction register.

 That's 5 more gpio than the C64, which has PortB and pa2 of one CIA. Sure, it only has on serial shift register rather than two, but it has the port with both read and write handshaking and 6 gpio in addition, so I think that counts as an upgraded.

No inside info, but my guess is it shows up in the emulator when they have the magic banking via $0000/$0001, because that's what 12 of those gpio are used for in the prior build. No guarantee is shows up in the same revision, but it certainly cannot show up earlier.

For instance, four tristate 8bit flip flops, latch enable tied to pb4, each one with output enable tied to pb0 through pb3, and each one tied the correct way to a db9, and you have a four joystick input port. IIRC, with a different layout, you could have two Sega 6button Arcade controllers (each one needing three pb gpio lines).

Edited by BruceMcF

Share this post


Link to post
Share on other sites
8 hours ago, TomXP411 said:

No, the RAM and ROM cannot be overridden by the expansion slots. The expansion slots get 32 bytes of dedicated address space, so that's not enough for a ROM. Instead, driver software should be loaded from SD in the autorun script. 

The "cartridge" slot is the SD card slot. User can swap out SD cards and reboot, and an SD card will have some sort of autorun mechanism. 

The User port is basically 14 GPIO lines, along with some interrupt driven control signals, which can be used for a printer, modem, or which can be arbitrary controlled for other devices.

 

The expansion port has all 16 address lines, the ready line and the line to tristate the 65c02 data and address ports, so technically it COULD, but it's not like the C64, automatically detected at power up and executed by the system start up routine ... detecting the system start up, and injecting code into the CX16 RAM to be executed would be entirely on the expansion card. So it couldn't be a passive ROM, but would have to be something like an AVR8 acting as a bootloader.

  • Like 1

Share this post


Link to post
Share on other sites

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.

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.

Maybe an Expansion card can even detect a reboot via the characteristic memory access patterns of the bootup process and act upon that. Not sure if that is a feasible approach, but It seems not too far off.
(I once built a Kickstart switch for the Amiga 500 that was controlled entirely via "magic" memory access patterns, so that I could switch the ROM without needing a hardware switch. (I didn't want to damage the case.))
On the other hand, an autostart program could just tell the card when a reboot has happened.

Edited by Fnord42

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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. 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
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.
 

Edited by BruceMcF
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use