Minerva Mk2 Remake

[aalea]

Hi,

I have cloned the git repository.

The original Minerva design did not extend the ROM area into the ROM Port, and only 32K ROM EPROM was used, this allowed the ROM PORT to be free.

If a 48K ROM, Minvera with Toolkit 2 added the end is used, the ROM Port is disabled, so hardware like QIMSI can not be used.

I think Minerva is 48Kb, without TK2, on a 27512 IC (64kbytes), in any case, yes, Minerva do not use the lastest 16kb and always leave free this area for the ROM port.

This do not always happens with three party adapters, and some come with added TK2 and use the full 64kb area.

I need to check the GAL equations, but the idea of this design is the same, use a 64kbytes IC, but only the first 48Kb, for minerva, without TK2 and leaving free the ROM Port.

If you look at the Trump Card design, the Toolkit 2 ROM is located $18000 leaving thd ROM Port free. This requires added logic to link the Toolkit 2 code in.

The Minerva I & II designs do not use use this method.

Personally, I prefer the the Trump Card approach, which leaves Toolkit 2 on the expansion card and the main ROM on the plug ROM board. Where either Operating System or Tookit 2 can be updated indpendently of each other.

Well, I have other design (minerva MK 1?? like) but used a 512Kbytes EEPROM, using 3 dip-switches, I can select between 8 diferent ROMS, and with a 4th dip-switch I can enable or disable the lastest 16kB, In this way I can have several version of the ROM, and also several version of the TK 2, I put the dip-switches in the outside of the QL and can select very fast which rom to boot before power on.

I agree that leave free the cartridge area is a must, not only with devices that plug in the cartridge slot, it's also the only way to have a Qbide and a trump card at same time, but having this option has been very usefull to me in the past, for example, When I only had the CST V3 Disc Interface, that do not have TK2.

My idea is to mix both ideas, to be able to use minerva+RTC but also other ROMS, and enable or disable the use of cartridge space using dip-switches.

[Derek_Stewart]

Hi Derrick et al

There is a simple GAL update that allows you to selectively enable/disable the upper 16KB of the onboard 64k EPROM (disabled in the original design).

With the addition of a micro SPDT (or should that be a DPST???) connected to the board with a flying lead (3-way), you can then have the best of both worlds - with our without TK2 occupying the memory-map shared with the ROM port.

You can find the updated GAL code posted (by me) elsewhere here on the Forum - let me know if you can't readily find it and I'll search on my laptop and upload the JED file again.

Happy Minerva'ing!

Try:viewtopic.php?p=43595#p43595

[martyn_hill]

Ah yes, that's the thread I was remembering - thank you!

I see now that the zip archive I uploaded only included the original plus a more readable version of Tony's original EQN file.

I've since found my updated version 'v1.10' - attached here.

This version uses Pin 6 (which I chose to rename to 'UprROMEn') and, after cutting the track connecting Pin 6 to Vcc and wiring a simple switch to it, connecting Pin 6 either to either Vcc or Gnd, you can select whether or not the 64Kb EPROM is enabled during accesses to the upper 16Kb/ROM area.

The cleverness is all Tony/QView's and not mine - I just tweaked it a bit...

[Derek_Stewart]

HI aalea,

I like your KiCad design, but there seems to be a problem in the PCB layout with the footprint of R1, R2, R3, also if a DRC is run there is many errors, as is the schematic when ERC is run, many errors.

Sorry to point this out.

I do not like this offset ROM socket idea, that is present on the modern ROM carriers, but a fair solution.

My plan was to make a direct copy of the existing Minerva MKII design, thus preserving the design for posterity, then add enhancements.

[aalea]

HI aalea,

I like your KiCad design, but there seems to be a problem in the PCB layout with the footprint of R1, R2, R3, also if a DRC is run there is many errors, as is the schematic when ERC is run, many errors.

Sorry to point this out.

I do not like this offset ROM socket idea, that is present on the modern ROM carriers, but a fair solution.

My plan was to make a direct copy of the existing Minerva MKII design, thus preserving the design for posterity, then add enhancements.

Yes of course, but all this errors are know and aceptables, let's me explain:

• There are erros with resistors and with the symbol of pcf8563, they are not part of standar libraries, but you should be able to see and use it, I'm not sure.

• There area a lot of errors because of the address pin, as they all inputs but none outputs, similar thing happens with Vcc, +5V and K, because not all chips get the propper power supply.

• There are a lot of errors because overlaped footprints and silkscreens outside the PCB board.

I analize it one by one (well I try) and none will affect the operation or manufacture of the PCB.

Also, with the post of Martin Hill is clear that the pins 6 & 7 of the GAL are wrong, I will update the schematic soon.

Go back to the original design shall be easy, remove U2 and put 1x01 conector in place of pins 1,20 & 22, you need also to interchange the VCC and A15 conections on Pin 1, and you get the original design.

I try to put the tracks with the same route than original PCB, but size is not the same, so not a 1:1 copy, it's only a starting point for aditional develop.

[Derek_Stewart]

Hi aalea,

The PCB project is really good and I do not mean to criticise your efforts,which are better than I could produce.

My idea was to reproduce the hardware, once completed, have a library of hardware designs that are useful, not just a user of photographs of the hardware that was available for the QL

[t0nyt]

Although I'm not too bothered about Minerva ROM side of things, quite happy with JS, what I'd really like, more than anything else on my QL, is a plug-in (given my lack of soldering skills) battery backed RTC solution for the QL so I can be sure development files are always correctly time stamped without me having to remember to set the date/time every time...

The chances of getting a Minerva Rom with RTC (or GC/SGC) seem very slim to nil these days

EDIT: Just to clarify I'm not talking about file time stamping as in DOS (is that kind of file timestamping even possible on the QL?) but I've been working on a utility for making automatic timestamped backups of my master development floppies and would like to be able to just pick up the date time for folder/file naming

[tofro]

EDIT: Just to clarify I'm not talking about file time stamping as in DOS (is that kind of file timestamping even possible on the QL?) but I've been working on a utility for making automatic timestamped backups of my master development floppies and would like to be able to just pick up the date time for folder/file naming

It is. The QDOS file header has provisions for an update and a backup date. The former is used by DD2 drivers (you need TK2 for it, or Minerva, which also maintains the dates, even on Microdrives) to maintain the date/time the file was last written to, while the latter is only used by specialised backup applications. Note the Microdrive driver is not a DD2 driver, no dice here except you use Minerva. If you have at least TK2 installed (or SMSQ/E), the file update date will be automatically maintained (as long as the clock is properly set) by the system. TK2 also optionally maintains a file version that allows you to implement your own version management.

TK2 (and SMSQ/E) supply functions to set/retrieve those dates (FUPDT, SET_FUPDT).

[t0nyt]

Many thanks Tofro

[Peter]

The chances of getting a Minerva Rom with RTC (or GC/SGC) seem very slim to nil these days

Would a QIMSI with buffered RTC be a solution?
Hardware-wise an I²C RTC and buffer are prepared on the QIMSI PCB bottom already.
I'd need to develop a (moderate) FPGA change and some software to read / write that RTC.

It would not be very cheap, because I was lazy enough to re-use the Q68's I²C RTC with integrated quarzt.
Also, an extra variant would complicate logistics (it's unknown which variant will be needed in which quantity, resulting in excess parts).

That's why I didn't come up with QIMSI RTC in the first place. But with sufficient interest, I'll think about it.
Might also be nice for aged (Super)GoldCards with empty batteries. (I don't particularly like my tinkered battery replacements.)