6502.org

Yes, exactly.

We're not "fooling" anyone. Rather, we're simply "under specifying". The internal chip select logic within the MCU is quite specific, whereas, we're just a bit more ham fisted. So, your 64K is essentially mapped to "everyplace the MCU DOESN'T map to".

You can see that if you wanted to map your 64K to bank 1, we'd need to check that A16-A23 equals "00000001", and you can imaging the gates and circuitry necessary to discern that. That's one aspect of what makes the CS logic on the chip so nice. They reduced a whole bunch of decode logic to just a few pins for us to use. Combined with the automatic decoding of the A16-A23 (which are normally multiplexed with the Data Bus), and you can see how the MCU simplifies a bunch of the support circuitry needed for an '816.

Again whartung did respond faster

Yes, this way you "fool" the processor somehow

The QBX board seems to be wider than 600 mils. Perhaps you could mount the RAM directly under the board between the pins? As you don't need to care about the address and data bit order, there should be only a few wires really necessary. Of course - using a socket and a perfboard is saver.

@ whartung & GaBuZoMeu

I very happy that we were able to finally settle that issue

And thank you very much for all the patience responding my questions, so far I learned a lot in this thread.

Really appreciate all help and advices received.

@ GaBuZoMeu

Could you tell me the part number of the 128K chip your are using?

On Mouser I found the AS6C1008-55PCN (SRAM 1Mb, 2.7V-5.5V, 55ns 128K x 8 Asynch SRAM) ... I am not sure if this one would work because of the "Asynch" ...

Regards.

The AS6C1008-55PCN is fine. If you keep the wires for Vdd and GND (Vss) short you may omit a 100nF ceramic capacitor between them, the QBX should be decoupled sufficiently. Don't forget to wire the CE2 pin (30) to Vdd. A16 (pin 2) may be wired to GND, Vdd or even to A14 (pin 3). Just don't let it float

Good Luck!

Great!

Now as hardware wise things got aligned and clarified, let's check the toolchain.

Example Assembly: Compile with "ACME" (https://github.com/meonwax/acme): Disassamble with "Dispel" (https://github.com/pelrun/Dispel): Resulting code: Looks good to me

FYI I am on macOS

Regards

That's not what you want to do.

Instead, what you want to do is store 'WDC' at 00:0800. Then, at 00:0804, you have code to start things up. The monitor looks for WDC at 00:8000 and 00:0800, then jump to **04 (as appropriate) if it finds it.

A simple example, is you could have a large program/dataset that consumes all (most) 64K of RAM. (it doesn't have to be large, just have segment that go to where the ROM is.)

You then load that via the monitor using S28 records, in to Bank 01. This lets you load all of it (notably the stuff that lives behind the ROM). The minor trick here is convincing your assembler/linker to let you build the code as if it's in Bank 0, but create the memory image (and thus the S28 records) as if it's in Bank 1.

Now, part of you start up code will be setting the proper control registers to disable the ROM, then you can jump in to that behind the ROM code and show that it works.

The other alternative, is to convince the MCU that the internal ROM doesn't exist at all. But out of the box, on the QXB, I don't think you can do that. Your BE line is tied high on the board, whereas on the SXB board, BE is tied high AND it is run out to an expansion header, and you could tie in to that there. It seems, though, if you had two buttons -- one for RESB and one for BE, if you held them both "down", driving them both low, if you let up the RESB button first, and then the BE button, it will boot to the external ROM. If you just press the RESB button, it'll boot to the internal ROM. There doesn't seem to be any time requirement between when RESB goes high and BE goes high. Just that they both need to go high for the system to reset. If RESB goes high after BE, it uses the internal bits. If RESB goes hight before BE, it boots externally. Obviously for a permanent project, you'd need the reset circuit to handle the timings of the two signals.

But, anyway, loading stuff in to Bank 1, and leveraging the WDC signatures at 00:8000 or 00:0800 will let you blame with swapping the ROM in and out.

You can do a simple test to have a simple program behind the ROM that lights up the LEDs, that way you won't have to figure out how to bootstrap the services that the monitor provides.

The two button trick makes testing a ROM pretty easy, I think. If the your "ROM" works, it works! If not, just hit RESB and you're back to the monitor ready to try again. In contrast, if your WDC code fails, you have to make sure you lose the signature in memory somehow to restart the machine back to the monitor. This may mean keeping the machine powered down for several seconds for the RAM to lose it's contents.

@whartung

Totally my fault ... I should have explained better in my previous post.

It's not about the code ... which is pretty pointless ... it was about the toolchain and 24bit addressing.

Look, I don't have any 65xx hardware at the moment ... (both boards are still in transit) ... so the only way I've left to 'run' code is in VICE. The possibility to address 24bit and work with 16bit accumulator is totally new and still have to do my homework and read a whole bunch of documentation covering that topic.

The goal of the code example was to virtually test how 24bit addressing works from the assembler side and if it would disassemble correctly once compiled.

Sorry for the confusion, I should have used 'QBX' instead of 'WDC' to avoid making you think the intention was to replace the monitor. This could be a future goal ... after growing up a bit

But you touched another interesting point ...
Ok, BE is always HIGH which leaves us with only to options as of table 1-5 of the data sheet.

BCR7=0 ; Internal ROM Internal Processor
BCR7=1 ; External ROM Internal Processor

and in the data sheet it says ...
Doesn't that mean one can activate/hide the internal ROM at will any time by toggling this bit?
Edit(1): correcting code toggling BCR7 bit

Regards.

The file I posted here viewtopic.php?f=2&t=5077 contains my Java based assembler (which does 65816 code) and an 816 emulator you can run in a Windows command shell.

The example code for calculating Fibonacci numbers is already configured for 65816 (but only uses 6502) instructions).

@ BitWise

Thanks for the link and info ... downloading ... being java hopefully it will run on macOS too.

Regards.

The assembler definitely runs under Linux (I've run it under PC Ubuntu and Raspberry Pi UbuntuMate). The assembler source is here
https://github.com/andrew-jacobs/dev65
The source for the emulator is on Github and can be compiled for *nix too.
https://github.com/andrew-jacobs/emu816

@ BitWise

in "program.cc" line 189, change:
to
otherwise it generates a couple of errors like this one:
Regards.

@ BitWise

reporting success ...
BTW What are the units of the execution count ... cycles ... instructions?

Regards.

It's cycles.

Sorry, about reposting this ... but the previous post should have been posted here to document the progress of this project.

Hi folks!

just a brief update on how this is going ...

It's about two weeks that the QBX board has arrived. The first impression was not so good,
as it arrived in a simple antistatic bag as any $2 chinese board would. The only visual
difference is the "MENSCH" sticker which seales the bag.

Considering the selling price of about $40 and the historic relevance of this SBC as a
6502 successor and educational value they should have done a better job.

After mounting the board on a breadboard and checking out the monitor and that it was
operating, I soldered the missing (and not included) header pins for the J1 and J2
connectors and wired it up with an external 32kB Cypress SRAM:

Power, /CE => A15, DIR => WEB, /OE => GND and the remaining address and data pins.

This configuration worked right from the first power up. No need to enable registers
or do other prep work from within the monitor.

After writing some assembler routines, loading and invoking them through the monitor, I
got the tone generator working but the waveform is a bit crude resembling what you get
out of a 4-bit DAC.

Yesterday I got the UART0 working and tested communication with an Arduino UNO software
serial. For later I am planning to connect to a ATTiny85 mcu which I'll to use as a
bridge to connect to several I2C devices, starting with a RTC clock module to be able to
initialize the current time and date via monitor user command reading from this device.

Regards.

Hi all!

Time for another follow up of this project. First of all I want to show you guys the "real thing" mounted on a breadboard.
I think it's a miracle by itself that it is working given the mess of wires going all around the board.

Until now I didn't pursue a specific goal and just to played around with the components and figure out how they work.

Yesterday, I added the ATTiny85 I2C Bus Master which receives it's commands and data via UART0 from the QBX. The firmware for the '85 was done in Arduino with the help of the TinyWireM and SoftwareSerial library and writing the testing the sketch took only a couple of hours -- easy. For the connections 4 out of 6 pins are required do the job. Still having at least one pin left (leaving reset pin alone for ICP) for some kind of interrupt propagation, when needed. But currently the firmware doesn't support this. It is even possible it to upload new firmware on the '85 leaving it plugged in the breadboard.

Another chip added yesterday was the 8KB NVRAM mapped to address $8000 along with an inverter chip driving the /CE pin. The goal of the NVRAM is to develop an own monitor (extension) with addional functionality over the on-board monitor. The lack of move, assembly and disassembly really bugs me a bit.

Edit: Something similar to the commands from the monitor of the "The Final Cartridge III" from the good old C64.

The current configuration is able to talk to 3 I2C devices: RTC Clock, Serial EEPROM, Motion Tracking Device. Only the I2C OLED didn't work out-of-the box (even it is working on the arduino). So I'll have a deeper look at this one and try getting it to work -- just for testing.

The goal I established to myself is to take this further adding a more suitable display (ex. 20x4 LCD module with I2C controller) plus a PC keyboard (PS/2) and some kind of removable storage (ex. SD card module with I2C controller) as well as an WiFi module (like the ESP01 controlled via AT command set and UART1).

Along with some programming work, this should give me a standalone, inter-connected tiny computer, and who knows at the end writing the text of the forum posts on it

Greetings!