I can't actually tell if it's better to have all the software running in external memory instead of dealing with sharing the internal and external ROM, having the stack in certain memory locations.

I've seen people running the 65xx cpus here alog with another MCU that fills the RAM with code while keeping the 65xx in reset state. Once having the code in place, the reset state is lifted and the 65xx CPU runs the code. I think that this RESET/BE lines game could be useful for that, so the '265s could be used with no internal memory at all, but with all the benefits of the embedded hardware and the complete 16MB addressability.

If I get my hardware delayed /BE line to work, the following could be having a button that could decide how to start the board. If that "BE" button is kept pressed while resetting (with another "RESET" button), then the /BE line would be kept high with no delay at all, so the '265s would boot with the Mensch ROM Monitor as usual. If the "BE" button is not pressed at all, then the delay circuit would do its job and boot from the external memory. A kind of "developer mode" boot.

I'm one of those people... All RAM in both my 65C02 (64K) and 65C816 (512/1024K) boards. I only have a 256 byte 'window' at $FFxx though - enough to poke in a bootloader, the reset vector, then it can pull the rest talking ot the host via the shared RAM and Rdy line (activated by WAI)

For the '134 board I just ultimately want the 32/32 (flash) ROM/RAM split. (although the ROMs going to be 4 banks of 32K switchable under software with the top 12KB identical in each of the 4 banks as that's where the OS is)

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

After some modifications to my board, I finally got the delay I was trying to get.



I added another 74HC00, to be able to debounce the best way they say, the reset circuit. I added a SPDT non-locking push button to get the RESB line go low and high after releasing it. And I put a RC network before the BE line so I finally got this 375ns (shown 0.375 us) delay.



I also programmed the EEPROM with a copy of the Mensch ROM Monitor in the same memory location where the internal copy is ($E000-$FFFF), but with a modified compiled date:



The datasheet specifies that there is no max time of delay of BE after RESB for the emulation mode to be set and external memory used, instead of the internal one.



So I just can understand why it doesn't boot from the external chips... I'm doing wrong, or I'm misunderstanding the BE driven BCR setting.

Mistery solved: the BE driven BCR mode has no purpose other than testing the chip by using in circuit emulation mode. It has nothing to do with the use I had understood of making the '265s boot directly with external memory.

So now I have to think of another method to be able to have a kind of 'debug mode boot', and I think how I'm doing it:

I'm repurposing the debounce circuit I implemented as a way to cut VDD to the EEPROM chip, so the '265s will not be able to detect it while the push button is kept pressed while also pressing the reset button, or powering up the board. Once in booted in the Mensch ROM monitor, the user could release that button and have the EEPROM powered again, so it could be read and erased by using 265SXB-hacker.

In the meanwhile, I'd like to know what are the values needed to have a complete external memory setup for the '265s not to use the internal memory at all.

I've thought that

would do it, but I don't know if by doing that, I'd lose the access to all the internal registers in the $DF00-$DF7F area...

I did it!!!

I have a board with "user boot" and "debug boot".

I repurposed the debounce circuit, and now it's powering the EEPROM.

So as intended, I now have two buttons in my board:

- "reset" button
- "debug" button

If I press the "reset" button alone, it will boot to sxb-hacker directly, as I programmed the EEPROM with the hacker starting from $8004, and put the 'WDC' string in $8000.

If I press the "debug" button first, and while kept pressed I press and then release the "reset" button, the EEPROM gets no power and the board boots into Mensch ROM Monitor. Then, I can release the "debug" button so tbe EEPROM gets powered and access it to erase it if needed.

I also added



in the reset routine of the hacker, and I think this way the '265s is using only external RAM, but I have no equipment to confirm this.

Of course that this is all only proof of concept.

I received today the voltage inverters I need to continue this project.

I modded the LCD1602A module so it accepts 3.3v input. Actually, the voltage inverter is needed for the LCD screen itself to be able to show characters, not for the embedded microcontroller, that works right at this voltage.

One problem with the '265s is that there is no complete parallel port free for use. Everyone of them has pins used for several functions. It would be nice to have at least the port 4 with its 8 pins available, but two of then are used to select the EEPROM "partition" to work with.

I should then try to work with the LCD in 4 bit mode instead of 8, or relocate the funcion of P44 and P45 to another pins... Maybe I could do it with P76 and P77, that are two chip select pins that are not used by now (and surely won't be ever).

So I'll have to modify the hacker code to work with that. Good luck to me!!

No news is good news... sometimes.

At last I had to give up on my idea of recycling the NDS (Nintendo DS) LCD display, because the signals it needs are not generated by the EPSON chip... at least in the version I had.

The NDS LCD display is a custom design by Sharp only for that little machine. The technology is the same as the so called HR-TFT displays sold mainly by Sharp, but with a custom resolution of 256x192.

The EPSON graphics display I chose is not compatible with that panel. I would had to create a circuit that would feed the NDS LCD with the signals it needs. I've found two ways of doing that: FPGA or CPLD. And I want not to use either in this project. Mainly because I would had to learn either one of the technologies, but also because the complications of having the extra circuitry just for that task.

But... wait!! there is a EPSON chip that supports Sharp's HR-TFT panels!! But it's MCU interface is 16 bit only. I would need extra glue logic to get the '265s to work with the chip, like a latch or something. And I'm sure the code would had to be adapted to that condition.

So in the end I ordered a compatible LCD panel that also increases the resolution to 320x240. I wanted not to cross the 1 byte barrier, to made the graphics data handling easier, but it seems I'll have to live with that.

I could also get a 176x220 lcd, but then the machine would have less resolution than a ZX spectrum!!

And I could get a 400x200 or even a 480x320 one, that would make this a little computer by itself, easily having a 80 columns display, but that's not the purpose of it...