I'm feeling a little frustrated at the moment, so please take any rants as unintentional...

I've been trying to use one of the 265SXB boards as a floppy controller, and while I am getting some success, there also seems to be some peculiar things happening along the way. I'm hoping that the people here who are much smarter than I can give some suggestions.

When I first started, I disabled the 4 UARTs and used ports 5 and 6 as i/o pins, which gave plenty of pins to interface with the floppy cable. I connected the i/o pins straight to the cable. During testing, I noticed that the commands were not consistent, and I often saw things that I hadn't told the drive to do. A closer look showed noise on the lines, so I connected them through a couple of 74LS245 buffers. This made things better, but there is still noise on port 6 whenever a key is pressed on the host keyboard...ghost signals from the uarts perhaps.

So I changed to using ports 4 and 5 instead. This made things worse, as commands just plain don't work. Even my code doesn't seem to work anymore, which I can't explain...I'm getting caught in loops that shouldn't be able to happen (dex should eventually get to zero...)

As a final effort I turned the address and data bus off so I could use ports 0 and 1. When this is active, uploading srec data fails miserably. Also, entering data on the pc keyboard is spotty at best.

So, I'm a little frustrated, and wondering if I'm just doing things wrong. The only thing I haven't tested is to pull power from the floppy drive and ttl chips from the same one as is powering the PC and USB port that the 265SXB is connected to.

What else might be good to test here?

EDIT: I've created a repository to share the code. It has been built up over a few iterations and isn't very clean, but it should work. You can find it at https://git.cureau.dev/65C265sxb-projec ... controller

EDIT EDIT: I found a glaring bug from when I was using ports 4 and 5, so now the code is doing what it should be doing. I've moved the wires back to ports 4 and 5 and will update the code. However, pressing the reset button doesn't actually do a reset until the drive power is turned off, which is also weird behavior...

Just to close the loop here...I was shown that the things I am seeing are expected. The USB serial isn't a separate UART...it is using port 5 and 6. Port 4 also controls /RESET, which I disabled.

My goal was to have a one-chip solution like the Arduino or ESP32, but I can't find enough free pins to do this for a floppy cable without losing functionality I will need later. So from this point, I think it might be best to just hang a 6522 onto the bus and use a port to control it.

The problem with the 265SXB is that it's hard to work with when you want to use the included ports while accesing external RAM and UARTs.

All those pins have shared functions and while having great flexibility, it will be achieved only when working with the internal ROM.

So the solution is to have external chips doing whatever the internal chips are doing, just like you suggest.

One of the more important features the 265SXB has is the non-multiplexed 24 bit address bus, that would in theory allow access to the full 16MB of addressable memory with no external logic, something the standard 65816 can't do.

That, if you want to use the 265SXB "as is": The intended goal for this MCU is to develop software in a way that once tested and ready for production, would be manufactured with a ROM containing that software instead of the ROM monitor.

Maybe you could take a look at the MyMENSCH Rev-B SBC, that allows for much more flexibility than what the 265SXB can offer.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I think the MyMENSCH is more flexible than the 265SXB.

Yes, premade solutions offers limited learning potential - but not "zero" learning potential.

If someone wants to design a solution that uses cpu, memory and communications and wants to learn how to make the chips work together, a thing like the 265SXB or the MM won't teach that much because it's all done.

In the event that someone wants to go further, like designing a solution that implies the use of chips beyond the basic stuff (cpu, memory, communications) then those MCUs offer that basic all-in-one design premade so the focus can be put on the external chips.

The problem is that both of them are very expensive for what they offer but I don't think WDC is thinking in hobbyists when offering their products but companies that would want to develop with a basic platform to start working with.

>$80 for a SBC that it's actually a FPGA chip running emulations of different 65xx chips and offer several features that aren't available without that FPGA chip like hardware math accelerators or interfaces to things like SPI or USB is not something that could be tell is worth of that price.

That kind of emulation can be obtained with cheaper alternatives that offer the same or more running free software, for example:

http://telmomoya.blogspot.com/2016/06/c ... cored.html

I'm glad to see some thoughts here...it's good to see that people have opinions. I'm still forming my own regarding this MCU. The reason I decided to use it is because I had some unloved SBX boards here, and I wanted to see what it was capable of. Sadly, 3.68MHz is not enough to read the bits from the floppy as I've discovered, so I decided to try hacking on the QBX board to see what I can do with it.

My first goal was to get SRAM working, which was a breeze. I removed the resistor packs that connect Port 7 to the LEDs and soldered a wire wrap line from /CS3 to /CE on the SRAM. Eventually I'll use additional SRAM chips and a CPLD to carve out the memory.

The struggle I have right now is running without the internal ROM. According to the datasheet (and some support from David Gray) if the BE pin is low when /RESET goes from low to high, we are instructing the chip to use external ROM..circuit simulation mode as the datasheet calls it. My thoughts here is that if this condition happens, the internal ROM should be completely bypassed. I'm not seeing that behavior. I'm not sure yet that I just haven't given enough time between RESET and BE going high, or if there is some other thing that I'm missing.

At the moment, I've removed both the /RESET and BE pins from the board - both are lifted from the board and have wire wrap wires connected. I'm using a MCP100 supervisory chip to provide the /RESET signal. There are two lines coming from the /RESET pin on the MCP100, one going directly to the reset pin and one that winds through two gates of a 74ls04, then into a 47k resistor, and then to the BE pin. I've attached a capture from my scope to show what is happening during boot.

What I see is that the internal and external ROM seem to be in conflict with each other...the cpu executes something over and over, but it's not what is programmed on the external flash as I would expect.

Has anyone been down this path before, or someone who knows how to more reliably control the BE pin and leave it available for use after the boot sequence?

Looks like I was too quick to write. @tokafondo has made the point here that the ROM can't be disabled. Oh well.

Given that, I guess I can get the system going with the WDC string in the ROM. Now to see how fast I can push the thing, given I am limited on how fast the chip can start up...

The '265 is able to run with clocks up to about 8Mhz by itself, as the internal ROM monitor is ready to accept that frequencies and configure the serial ports connected to USB.

I managed to get it working connected to the expansion port of a Commodore 64, the outputs a clock signal of ~8mhz

Please note that I'm talking about the '265 MCU instead of the any of the SXB or QBX boards that features it.

In theory you can remove the included clock can and put a faster one.

And in theory you could make the MCU faster than the certified 8mhz by disabling all the internal stuff (rom, ram, serial/parallel ports and others) and using only the '816 core, provided that you wired all the needed chips externally through the data and address buses and the other control lines.

This is the only known way (by me) to have an '816 cpu (or core) running with the full 24 bit address available with no demultiplexing needed

My plan was to use what I already had on hand, and the QBX board was such a disappointment when I got it many moons ago that I didn't feel it was a loss if I broke things on it. Eventually these experiments will turn into a much more feature-complete board for my own use. It'd be good to document it all too...eventually.



A friend of mine has already gone down the route of a plain 65816 and the lack of a full address bus. I'd like to not have to worry about demuxing. Fewer chips (or cpld cells) and easier to use. Turning off the chip also allows me to use nicer components, like an external quad UART and such that are nicer to use than the 6551.



And this was the goal...not having to deal with the address space demux. That and pushing the limits. Since I know I can't turn off the ROM now, I'll have to see how to dynamically jump into high speed mode once the embedded ROM is out of the way.

Well, progress is being made! I've got a simple breadboard set up with a 6551 and a 6522 for testing purposes. Since I'm still using the QXB board, I removed the resistor packs across the port 7 LEDs and soldered to CS0, CS3, and CS4. SRAM and flash work just fine, but I'm having some trouble capturing and using the CS0 signal.

From the datasheet, CS0 is linked to the DF00-DF1F range of addresses. So, I used a 3-to-8 decoder connected on A2-A4 and activated with CS0 low, which should give seven CS signals of four addresses each. In the circuit, however, it doesn't seem to be working as it should. As an example, I have my logic analyzer watching A2-A4 and the CS0 lines as I attempt to write to port 4 (should be $df10-$df13). I can see CS0 go low for $df11, $df12, and $df13, but $df10 stubbornly refuses to go low. A0-A2 are acting appropriately.

A further look at the datasheet shows a couple of notes:

Note 2: When on-chip ROM, CS3B and/or CS4B are enabled, then CS5B decode is reduced by the addresses used by same. CS0B and CS1B address space never appears in CS2B, CS4B or CS5B decoded space.

Note 4: CS0B is inactive when 0xDF00-0xDF07 are used for internal I/O register select (BCR0=0) when (BCR0=1) external memory bus is enabled CS0B is active for addresses 0xDF00-0xDF1F.

Since I'm not using CS5 (yet) and it isn't enabled anyway (only CS0, CS3, and CS4 are enabled), the only thing that should matter is BCR0. The monitor ROM sets it to 1 after a reset, and I've verified that it doesn't get changed. Adding BCR3 (emulation mode) doesn't change the lack of CS0 for $df10.

I've sent a follow-up email to David Gray about this, but I thought that if someone here might know, then that puts me a little further ahead.

EDIT: connected to all of the decoder's pins and did a tight loop to write every address from $df1d down to $df00 and then repeat, and I see all sixteen signals on the proper lines. This has to be a code issue.