Page 2 of 3

Re: The forum is NOT read-only!

Posted: 26 Jan 2014 18:51
by Bill B
Memu-pi provides a GUI for the main options, although by no means everything that menu can do.

On Linux, even if you don't have a pi, you can download the code and compile memu-
Cfg, which with just the option -config menu.cfg gives you the same GUI. Unfortunately, I have never sorted out windows compilation of this version.

Re: The forum is NOT read-only!

Posted: 26 Jan 2014 20:46
by Martin A
fifo 1-20 wiring.jpg
fifo 1-20 wiring.jpg (92.92 KiB) Viewed 10542 times
fifo1-20 top.jpg
fifo1-20 top.jpg (57.83 KiB) Viewed 10542 times
I've been playing with FiFo's !

The 2, 16 pin chips, are 4 bits by 16 fifo's, that's right folks a 16 byte memory card.

A fun occupation, however, if I can get my head around a memory device with no address bus, then I'm told it's the best way to communicate with an additional processor. Reverse BBC Micro anyone ???

I've had limited success so I didn't really want to say anything, but (big) Dave want forum post so ........

Re: The forum is NOT read-only!

Posted: 26 Jan 2014 21:32
by Dave
Martin A wrote: Reverse BBC Micro anyone ???
I've had limited success so I didn't really want to say anything, but (big) Dave want forum post so ........
An MTX Tube Interface - great idea . . .

And just look at all that extra board space you have to add a Motorola 6845 BBC (and Memotech FDX) CRT controller in addition to the 6502 CPU :-)

regards
(medium sized) Dave

Re: The forum is NOT read-only!

Posted: 26 Jan 2014 22:37
by Martin A
Dave wrote:
Martin A wrote: Reverse BBC Micro anyone ???
I've had limited success so I didn't really want to say anything, but (big) Dave want forum post so ........
An MTX Tube Interface - great idea . . .

And just look at all that extra board space you have to add a Motorola 6845 BBC (and Memotech FDX) CRT controller in addition to the 6502 CPU :-)

regards
(medium sized) Dave
and I guess you'd want a 1772 FDC and a teletext chip and a couple of 6522's for a user port and MHZ bus as well ??

Re: The forum is NOT read-only!

Posted: 26 Jan 2014 22:55
by Dave
Well . . .

as you seem to have offered, where do I sign up?

:-) :-) :-)

regards
Dave

Re: The forum is NOT read-only!

Posted: 31 Jan 2014 00:33
by Martin A
Well the smallest capacity ever MTX memory expansion would seem to be working.

Up to 16 bytes can be fed into the fifo by writing to an output port, and read back from the same port, in the order they were written.

The status port that can be checked to read the status of the empty and full flags appears to respond as expected.

The next step is to expand the design, to have 2 fifo's, with one read and one write port on each "side" instead of the situation on the test card where the read and write are both accessed from the one MTX I/O port.

It's not a Tube, Acorn had something like 8 (I think) fifo's of different sizes in their design, but it's a start.

Re: The forum is NOT read-only!

Posted: 31 Jan 2014 00:49
by Dave
Hi Martin,

it sounds like you're making good progress!

If it's not a tube, at the very least, it does sound like you have a small pipe connected so far :-)

regards
Dave

Re: The forum is NOT read-only!

Posted: 31 Jan 2014 04:07
by 1024MAK
Hi Martin :D

:idea: Have you considered using any Dual-Port Static RAM? :?:

:arrow: E.g. 1k x 8 bit Dual-Port Static RAM DIP-48 like IDT7130SA55P or CY7C130-55PC ? :?:

Mark

Re: The forum is NOT read-only!

Posted: 31 Jan 2014 11:53
by Martin A
1024MAK wrote: Have you considered using any Dual-Port Static RAM?
I did consider dual port ram. A while back, I built a Z80 co-processor to fit in my RiscPC, that uses an IDT7132 2k dual part ram for communications.

However, although I've got it running BBC Basic Z80, I can type in program lines and run then, there's one big issue I've not been able to work around.

The dual port ram allows reads from both sides of a memory location, writing and reading at the same time, or both side writing results in one of the operations failing.

Since I couldn't figure an easy way to track the /busy signal I tried doing it in software using semaphore locations.

After a period of running it locks up, as the software on both sides ends up in listen mode, so on the MTX I decided to look for a hardware solution.

Swapping to a FIFO arrangement looked easier than using /busy to force wait states on whichever side gets locked out.

Re: The forum is NOT read-only!

Posted: 31 Jan 2014 18:39
by 1024MAK
Dual port SRAM

In theory, on the Z80 side, using the busy signal to hold the Z80 in a memory or I/O cycle (depending on how it is interfaced) via pulling the /WAIT signal low may work. Alternatively, you can temporarily pause the operations of some CPU's (like the Z80) for short periods by forcing the CPU clock to stop. You do have to be careful with the timing. This is how Sinclair and Amstrad gave the ULA/gate array proirity over the Z80 CPU in the ZX Spectrum models.

Of course, not all CPUs have equivalent pins to the Z80's /WAIT and not all CPUs can behave with a paused clock.

I have not tried this in practice myself.

Mark