nedoPC.org

Hi, first post here! I hope not to go OT with this...

I've bought a KR1801VM2 CPU (it is on the way...) and I'm starting just now to try to "understand" this CPU.

I've seen your work on hackaday, but I miss a complete datasheet of this IC (and no, I don't speak Russian...).

I've found a partial datasheet here: https://bitbucket.org/cfib90/1801vm2/sr ... s/1801vm2/ but a lot of pages are missing (they should be about 166 pages).

The part I'm looking for is the "sequence" and timings for the DMA request "handshaking" (#DMR, #DMGO, #SACK) and if there is a sort of "Wait" signal to accommodate slow I/O (may be #SP1 and #SP2 pins???) and its timing.

As far as I've understood up to know the I/O is memory mapped only and there are two "pages" of 64Kwords (16bit wide) selected with the #SEL signal.
This second "hidden" page seems to be used for "special" purposes with a sort of exception handling (but I haven't any detail).

Regards.

J4F

Actually VM2 is trying to resemble PDP-11 (more precisely LSI-11) as close as possible, so you can read PDP-11 docs 1st to see how it's supposed to work.

We have a topic with timings taken from official VM2 datasheet - see http://www.nedopc.org/forum/viewtopic.php?f=95&t=18777 (unfortunately it's all in Russian, so you need to use Goodle translate or something).

Basically PDP-11 doesn't have WAIT signal - all data bus communications are happening with a handshake so any peripheral must response in handshake in order data transfer to happen, so if it's slow then it simply response slower (but it can not be too slow otherwise on-board watchdog will send chip to trap).

Hi, thanks for the info!

Currently I'm "exploring" your forum and finding a lot of stuff. Really a gold mine!

Here I found a really explicative paper on the KR1801VM2, that made me see "the light"...

More, it seems that I can "pause" the CPU with the AR signal as explained here.

I also noticed that the SP1 and SP2 signals (pin 10 and 11) in the original scanned documentation, are commonly called as WRQ ans WAKI.

Having a fully static design will help a lot during the experiment...

Now I have to read more documentations before to decide the approach to follow for the first experiments (KR1801VM2 + MCU, KR1801VM2 + CPLD/FPGA or both...).

Regards.

This is another project VM2+MCU that was mentioned in our mailing list:

https://github.com/jaquinn/RetroShield-KR1801VM2

Also WRQ and WAKI are window access commands for multiprocessor systems that share the same memory
WRQ - request to use window (output)
WAKI - acknowledge for window usage (input)
"Window" is part of upper memory 160000..163777 (1110 0000 0000 0000...1110 0111 1111 1111)
In my experiments I connected WAKI to ground and pull-up WRQ to +5V (in this case "window" is disabled and all memory is accessible)

Thanks!

That is near to the way I usually go with "legacy" 5V CPU for first experiments, using a breadboard-able custom board with the MCU + SD + serial (on USB), like I did with a V20 CPU:



I'm thinking to use the AR signal to stop the 180VM2 at the beginning of an I/O operation (I/O address space) and wait for the MCU "attention", followed by the data handshaking sequence made to accommodate the exception timeout (so from the MCU point of view this will be a time critical sw section with all the IRQ disabled; just a raw idea, I have to study this more deeply to be sure that it can be done).

It will be a "long term project" for sure...

Cool

Don't forget that there is "read-modify-write" cycle that is happening pretty frequently:



Here you have only one /AR but then read cycle and write cycle one after another for the same address

Thanks for pointing this out...

Not sure if this "read-modify-write" cycle can be really useful in the I/O address space too, where the read/write operations are in general not "symmetrical" (reading and writing in the same address can do different things). Of course it depends on the way the I/O HW is done.

Anyway the CPU is just arrived!




Now I've to find the time... currently playing with a 68008 CPU... we'll see...

Problem with read-modify-write cycle is it's happening very frequently even when it's not needed, so you need to make it working even for IO (that I assume mapped to usual memory address space)