Commander X16

4 hours ago, TomXP411 said:

I don't even care about an expansion slot. I just want a enough of GPIO that we can have a serial port. Give me a UART and I can talk to the world.

The lack of the expansion slot is the big downside to me for the CX16e ... for instance, no expansion slot, no bus mastering 65816 card.

If both the LX8 and CX16 were on offer, but neither of the real CX16 boards, I would likely getting the cheaper LX8 and hold out hoping the CX16c crowdfunding gets launched.

And as far as tweaks, tweaking the LX8 USB so it supports a hub and serial seems like a lot less of an ask than actually totally ditching Frank's board design and doing a new one and calling it the X8.

Edit: Never mind, it uses a WiFi modem to emulate a serial port connection, so that last tweak is not as high priority after all. For me, the "tweaks", any of which might required a larger resource FPGA, are, in order of my own personal priority:

(1) Access Vera RAM using the CX16 I/O page approach in addition to the native "roving page" approach.

(2) Include a soft YM2151 core

(3) A VIA core supporting a 3.3v version User Port via block pin header

(4) An FPGA with enough RAM resources to have 7 or more High RAM Banks (eg, if Block RAM that can be accessed as 32K RAM, implement $0000-$7FFF in Block RAM to free up more High RAM banks in SPRAM).

2 hours ago, Scott Robison said:

Wouldn't you need a WART to talk to the world? I guess the world is part of the "universal" charter of the UART. #insertdadjokegroanhere

o.O

Do we need to take away your keyboard? 

?

8 hours ago, TomXP411 said:

o.O



Do we need to take away your keyboard? 



?

You don't *need* to but it is probably advisable. ?

On 7/25/2021 at 11:25 PM, Guybrush said:

Two 6502's could also run on opposite phases of the clock ...

Did anyone on this thread already mention that this is exactly what the big CBM disk drives did? The 4040, 8050, 8250, etc...?

One 6502 was doing the IEC bus and file stuff and the other did block level disk access. They would communicate through memory locations.

11 minutes ago, pzembrod said:

Did anyone on this thread already mention that this is exactly what the big CBM disk drives did? The 4040, 8050, 8250, etc...?



One 6502 was doing the IEC bus and file stuff and the other did block level disk access. They would communicate through memory locations.

I knew the drives had their own CPU but I did not realize (or my old brain forgot) that they had multiple CPUs working collaboratively. Thanks for the lesson / reminder!

12 hours ago, Scott Robison said:

I knew the drives had their own CPU but I did not realize (or my old brain forgot) that they had multiple CPUs working collaboratively. Thanks for the lesson / reminder!

It's quite fascinating, really, and also provides a nice study in software architecture heritage. The 1541's DOS still shows this structure, only it simulates the second CPU with an interrupt driven disk controller routine. The job codes in the zero page that the file system and the disk controller communicate through - that was the shared memory in the 2-CPU drives.

On 7/30/2021 at 1:34 PM, Scott Robison said:

I think the only point is that some tasks will work better if the individual CPUs have access to private RAM that cannot be overwritten (deliberately or otherwise) by the other CPU. One memory map that comes to mind would divide the address space into two 32K chunks. The first half is private to a CPU (so each CPU gets its own zero page and stack; the stack in particular you do not want to share directly between these CPUs!). The second half is shared address space. Each bank can contain any combination of RAM / IO / ROM desired, including an ability to do bank switching to give access to even more public or private RAM / ROM.



Ultimately it doesn't have to be an even 32K split, but I think at minimum you'd want the private stacks, and probably private ZP, and perhaps even another page or two of private non-shared space.

Each processor would NEED to see $0100 - $01ff and $fffc - $ffff uniquely.  Zero page would also be desirable.  So...   $0000 - $01ff is RAM unique to each CPU.   $ff00 - $ffff is ROM unique to each CPU.  The rest can be banked.   The ROM stub at $ff00 gets run by the startup vector and sets up the initial paging state for both processors.  The rest of the ROM can be in shared or unique ROM, but will have to be paged in by the bootstrap and off they go...  It should be noted that you now have TWO IRQ lines and TWO NMI lines each of which can do different things and can run simultaneously.  This really does make for some really unique opportunities.   Signaling between processors could consist of dropping a message into shared RAM and kicking the other processor's NMI line.

On 8/24/2021 at 6:35 AM, pzembrod said:

It's quite fascinating, really, and also provides a nice study in software architecture heritage. The 1541's DOS still shows this structure, only it simulates the second CPU with an interrupt driven disk controller routine. The job codes in the zero page that the file system and the disk controller communicate through - that was the shared memory in the 2-CPU drives.

Yeah the older drives had a 6502 and a 6504 (6502 with only 13 address lines).  They did some "magic" with control logic so that the 6504's view of memory was offset from the 6502 by 4k.  This made the 2 processors pull their starting address from different places in ROM.  The 6502 talked to the IEC port and parsed commands, etc.  When it wanted blocks from the disk it pushed commands into a queue in RAM which triggered the 6504's IRQ.  It would pick up the command, execute it and RTI.   The main loop of the 6504 sat in an infinite loop.  In the 1540 and up there was only one 6502 and the trigger triggered the 6502's OWN IRQ to execute the commands.

Yes, along those lines, you could have an X16 expansion card with a 6502 that takes all of its RAM from a (say) 1KB dual port SRAM, addressed at $0000-$03FF, and on the other port accessed on the X16 system bus with the lower 4 bits of address space from an I/O port address, IObase+$10-$1F, and the next six bits from a latch addressed at $IObase+$00.

On 7/25/2021 at 9:09 AM, rje said: