8th Dec 2019, 6:04 pm | #281 |
Heptode
Join Date: Aug 2009
Location: Worthing, Sussex, UK.
Posts: 662
|
Re: Gemini 80-Bus System
I would check my conclusion first and then it is up to you. I have previously found the Gemini naming convention a little confusing in its correspondence to the physical format. Also cylinder mode should be slightly faster as there is less head movement. In addition the 765 controller can read both sides of the same cylinder in one command which is probably why cylinder mode is the surviving format on PCs etc.
When I did my matmos/alphatronic format I decided to allow it to boot from both 512 byte sectors and 256 byte sectors on DD/HD format. The original format was 256 byte sectors. This gives me the maximum options from the boot rom. For the HD system I built it with 512 byte sectors - with 18 sectors/track for 3.5 inch this easily mapped into its 1k sector buffer. In addition it meant the low level format was IBM PC and hence making it possible for me to create HD disks using a PC with a USB floppy drive. If you are wanting to keep your boot roms the same you are restricted to having sector 0. This removes any possibility of being able to create disks on HD 3.5 inch drives. My choice would be to confirm my conclusion and if correct re-publish rather than inventing a new Gemini format it will be less confusing in the future. However looking at multi.mac just after label readrw double is in cylinder mode while single density is in side mode. This corresponds to what you have on your rack system. So your rack system is the correct format at the moment. Its just that this does not seem to correspond to the definition of GEMQDDS in the multiformat system - and it appears the multiformat system has it wrong! |
8th Dec 2019, 8:00 pm | #282 |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
I think that it is me that has it wrong... The Bios that I changed to support GEMQDDS was based on version Bios 1.4 which was written for GEMDDDS. GEMDDDS uses C but GEMQDDS uses S. In using Bios 1.4 as a base I have created a GEMQDDS with side mode C, Doh!
I will look into it all when I am back from my trip, I may simply ignore GEMQDDS for the rack system now that I have the Galaxy to play with. |
12th Dec 2019, 8:30 am | #283 | |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
Quote:
Any thoughts or comments would be appreciated. Code:
;**************************************** ; Read/Write a Sector to/from memory * ; Assumes drive selected and destroys * ; BC & HL * ;**************************************** READWR: PUSH DE ;Save Track/sector ; Check Density and modify track/sector appropriately LD A,(DRIVEA) ;Get Drive BIT 4,A ;Check density JR Z,QUAD ;Skip if QD ; This represents 'Side Mode=S' ; Single Density, track goes 0-69 = 0-34 + side LD A,D ;Check range (track in D) SUB 35 ;35-69? JR C,SDDD ;Skip if 0-34 (carry set means side 0) LD D,A ;Modify Track to within the range 0-34 JR SDDD ;Skip (carry not set neans side 1) ; This represents 'Side Mode=C' ; Double Density, sector goes 0-19 = 0-9 + side ;DOUBLE: LD A,E ;Check it ; SUB MAXSEC/2 ;10-19? ; JR C,SDDD ;Skip if 0-9 (carry means side 0) ; LD E,A ;Modify sector (no carry meanes side 1) ; This represents 'Side Mode=S' ; Quad Density, track goes 0-159 = 0-79 + side QUAD: LD A,D ;Check range (track in D) SUB 80 ;80-159? JR C,SDDD ;Skip if 0-79 (carry set means side 0) LD D,A ;Modify Track to within the range 0-79 ; D=Wanted Track ; E=Wanted Sector ; Flag C=Side 0 ; NC=Side 1 SDDD: |
|
12th Dec 2019, 9:37 am | #284 |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
Despite my code above I am having second thoughts as I am even more confused about this Side Mode stuff. I have just noticed the diskdefs output you posted in post #9 shows that GEMDDDS and GEMQDDS both use the same Cylinder Mode (1). I am assuming Cylinder Mode directly relates to Side Mode?
|
12th Dec 2019, 10:52 am | #285 |
Heptode
Join Date: Aug 2009
Location: Worthing, Sussex, UK.
Posts: 662
|
Re: Gemini 80-Bus System
Don't worry about diskdef - the gemqdds entry was created using your definition of gemqdds - hence I made the same mistake as you!
What you have written is correct for S and C mode as commented. Please remember that for S mode SPT needs to be the sectors per track (eg 10*4in your case). For C mode the SPT needs to be the sectors per cylinder 20*4 in your case. The multiply by 4 is because there are 4 CPM 128 byte sectors per physical 512 byte sector stored on disk. Note that the diskdef definition of SPT is different. This is because the bios (installed by running mfb.com) always determines the side of the disk from the track number - dividing the cpm track number by 2 for C mode and checking for greater than the number of tracks per side for S mode. I enclose a image of disked from the Gemini 925 emulation with GEMQDDS disk setup. This is based on the image of the disk you sent me. (? key is helpful with disked) |
12th Dec 2019, 5:32 pm | #286 |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
That all makes sense. I will make the changes, update the website and re-publish the images etc.
Tomorrow I expect to be able to spend an hour or so investigating the Galaxy MFB, I will keep you posted. |
13th Dec 2019, 10:29 pm | #287 |
Triode
Join Date: Nov 2016
Location: Frinton on Sea, Essex, UK.
Posts: 45
|
Re: Gemini 80-Bus System
Hi
I have a collection of gemini boards, and trying to put a system together. Currently I have the following:- 2 ivc cards 1 813 cpu card 1 811 cpu card 5 826 batt backed ram cards 2 829 disk controller 1 pio card no code numbers but has two pio chips 2 math processor card no code numbers 1 5.25 floppy drive 2 powers supplies +5v +12v -12v all in a nice 19" rack mount chassis I have a cpm boot disk but its badly corrupted and only just loads cp/m and shows the directory, any attempt to run the programs on the disk reports CRC errors on various tracks and sectors. Can any one supply a good working 5.25 disk with cpm and all the standard programs on it? |
13th Dec 2019, 10:47 pm | #288 |
Heptode
Join Date: Aug 2009
Location: Worthing, Sussex, UK.
Posts: 662
|
Re: Gemini 80-Bus System
Slighty confused about your system.
You appear two to have two systems in that you have two video (ivc) cards, 2 CPU cards (GM811 and GM813). The GM813 has 64k bytes of memory. Two math processor cards. You also have two floppy disk controllers GM829. try the command stat a: dsk: if that works would indicate which format is used. Also anything written on the boot roms on the processor cards would help - possibly a version of Simon or RP/M Configurations similar to this were sometimes used in flight simulators. |
14th Dec 2019, 1:04 am | #289 |
Triode
Join Date: Nov 2016
Location: Frinton on Sea, Essex, UK.
Posts: 45
|
Re: Gemini 80-Bus System
I believe it was used in a flight sim, I Used to have a lot more bits but this is all that's left. the 19" rack has a back plain that's wired for three systems with a card that allowed two of the systems to work in parallel via a switching card to select between them.
got a small problem, fitted a ps2 to parallel converter but the keyboard input is a bit ify, the strobe is sent but if its not present during the flyback period the key press is missed, looking to extend the strobe pulse width or rewrite the rom to use an interrupt to get the key input. |
14th Dec 2019, 1:17 am | #290 |
Heptode
Join Date: Aug 2009
Location: Worthing, Sussex, UK.
Posts: 662
|
Re: Gemini 80-Bus System
Careful - it is not only the strobe that is missed, but I suspect that the data is not latched until the flyback period - hence the data needs to be valid as well.
|
14th Dec 2019, 10:13 am | #291 | |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
Quote:
Once I have the MFB system working, I will happily supply a boot disk. The rack system I have is using a $15 Chinese Gotek at the moment. Last edited by john_newcombe; 14th Dec 2019 at 10:20 am. |
|
14th Dec 2019, 11:54 am | #292 |
Triode
Join Date: Nov 2016
Location: Frinton on Sea, Essex, UK.
Posts: 45
|
Re: Gemini 80-Bus System
I think i'll change ic1 from a 74ls244 for a 74ls574 and use the strobe to latch the data, probably remove the 244 fit a socket and put the 574 on a daughter board that plugs in.
I can lend you a 849 card if it helps to copy a disk |
14th Dec 2019, 12:01 pm | #293 |
Triode
Join Date: Nov 2016
Location: Frinton on Sea, Essex, UK.
Posts: 45
|
Re: Gemini 80-Bus System
Forgot to add that I intend to use a bank of 1M ram chips (27c1008) on a prototype card to store file images and bank switch them in a similar way the N8VEM card does. the floppy drive is to keep the original system working.
May also add an IDE interface if I have the room on the card. |
14th Dec 2019, 7:07 pm | #294 |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
The issue I have is that the rack system that is working does not have a working floppy drive only a Gotek. The Galaxy MFB I have does have floppies, however, I have a few issues with it that I need to sort. At the moment I have at least one fault on the GM813 CPU and an intermittent issue on the SVC card. I will get to it in the next week or so.
I was just thinking that if you attached a cheap Gotek to your GM849 you could boot to CP/M from one of the raw disk images I have and copy whatever you wanted from there. |
23rd Dec 2019, 7:33 pm | #295 | |
Triode
Join Date: Nov 2016
Location: Frinton on Sea, Essex, UK.
Posts: 45
|
Re: Gemini 80-Bus System
Quote:
|
|
25th Dec 2019, 8:50 am | #296 | |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
Quote:
Last edited by john_newcombe; 25th Dec 2019 at 8:58 am. |
|
31st Dec 2019, 8:36 pm | #297 | |
Triode
Join Date: Oct 2019
Location: Carlisle, Cumberland, UK.
Posts: 11
|
Re: Gemini 80-Bus System
Quote:
MACHINE 1 began with a Nascom 2, 48K RAM-B and I/O board, with the Nascom keyboard and Phoenix monitor (the round-looking one often seen in Nascom sales literature). These were housed in a desktop case made by one of the aftermarket suppliers, but as this didn't come with a card frame the two upper boards had to be balanced on cardboard spacers, which wasn't great, although it ran NAS-SYS 1 quite successfully. I moved it all into a 19" rack, and expanded with a Gemini floppy drive, Gemini Winchester, FDC and IVC (later SVC), MAP 256K RAM, Microcode 14-slot backplane, and Gemini keyboard. This ran CP/M 2.2 with the MAP BIOS and Gemini-format disks. As an aside, I made a useful expansion board for this. Nascoms operate at 4 MHz. Analysis of the memory timing and worst case speed paths showed that, on my system at least, things would work correctly at 8 MHz except in M1 and I/O cycles. So I fitted the 8 MHz CMOS chipset and designed a clock board that generates an 8 MHz signal except in the two cases mentioned, when the speed is dynamically reduced to 4 MHz. The peripheral boards continue to operate at 4 MHz by means of the AUXCLK bus signal driven by the original Nascom clock, and a setting in the BIOS allows for the correct operation of timing loops. The improvement here was quite dramatic, even in applications I wouldn't have thought were particularly CPU-bound. When this entered service everyone else was using Windows, but I like the austere engineering beauty of a system in which I know exactly what is happening, with no processes I didn't explicitly start, and with fully documented hardware. I used this machine for my Ph.D., which caused comment, and extensively afterwards. This machine came to an end when the drives and monitor were accidentally thrown out at work. However, for the reasons stated above, I took the opportunity to separate the parts from the different manufacturers and revert to a rack-based Nascom-only. Nascoms were intended for use in both desktop and embedded control applications, and the rack-mounted configuration is more suited to the latter, not least because it obviates the need to find a keyboard enclosure that matches the system cabinet. My remaining system now comprises a Nascom 2 at the original 4 MHz clock speed, RAM B and I/O. These are mounted on the Microcode backplane (now cut down to 10 slots) and are shown in picture 1. The 1U front panel is a remnant of the previous hybrid machine and still has all its connectors; it will be replaced with a simpler one that just has the PIO and UART interfaces. I can't show it in operation because it isn't used for anything yet, but 'when I've more time' is going to be used to control the model railway. MACHINE 2 is a second-hand Nascom 3, the fully-fitted desktop system with Nascom 2, FDC, AVC and 'Nascom' 256K RAM (actually made by MAP-80). After ten years of disuse in the attic it came to light when we moved house recently, and didn't work. After programming a new boot EPROM, the next problem was the drives, which look to have been very early ones. Refurbished Cumana ones were obtained from the suppliers on ebay. I know Nascom did use Cumana drives, latterly the slimline versions, and although the bezels would have been black, I think these are reasonably authentic. Finally the RAM board was unreliable, the M drive frequently losing data. This too was an early version, with DRAMs of the slowest speed grade, and was conveniently replaced with the faster one left over from machine 1. This machine runs CP/M and is shown in pic. 2, together with the matching Lucas dot matrix printer. A Nascom 3 has two display controllers, the standard Nascom 2 48x16 monochrome text display, and the AVC; these can be used simultaneously. The AVC operates in two modes: high resolution monochrome and medium resolution colour. Pic. 3 shows the hi-res mode, compiling my LISP interpreter that I wrote using HiSoft Pascal, and I'm now using the machine to continue this work (the photo had to be taken at maximum pixels, and had to be compressed). Pic. 4 (likewise) shows the colour mode: the AVC output is sent to a separate colour monitor, while the monochrome monitor is switched to the Nascom 2 display and used for menus and commands, shown here running Nascom's LOTTI 2D drawing package. MACHINE 3 is an Gemini Galaxy that I'm now restoring. Again, for historical authenticity, I want to get it exactly as Gemini's designers envisaged it. I'll use this to run all the software that I lost the use of after the demise of machine 1. A Galaxy I came up on ebay recently, without drives, but including the GM813 CPU/RAM, SVC, FDC, RAM-disk and Climax colour board. At the moment it's having to borrow the Phoenix monitor and Cumana drives from the Nascom (pic. 5). At present it doesn't work; the CPU seems to be producing sensible signals at its bus interface but the SVC isn't communicating with it. I'll hopefully sort this out soon. It will be running CP/M 2.2 with the standard Gemini BIOS 3.2, and I'll let you know of any significant progress. Meanwhile, if anyone has a Gemini drive enclosure (with or without a drive) or a Phoenix monitor that they would be willing to part with, I'll be pleased to offer a good price for it. |
|
11th Jan 2020, 10:36 am | #298 | |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
Quote:
Good luck with the restoration and keep us posted. Last edited by john_newcombe; 11th Jan 2020 at 10:56 am. |
|
11th Jan 2020, 10:55 am | #299 |
Hexode
Join Date: Apr 2019
Location: Skipton, North Yorkshire, UK.
Posts: 252
|
Re: Gemini 80-Bus System
With the Christmas holiday now well and truly behind me, it is time to look into sorting the Gemini MFB. Alas, once again I am needing your help and expertise as the system is not working.
The unit consists of a GM813, SVC, GM849 (factory modified for Multi-Format), Xebec/HD and all floppies except 3inch. Basic checks of PSU voltages, cabling, sockets, card reseating/repositioning etc. have been undertaken with no change in symptoms. I have now reduced the system to two cards, the GM813 and the SVC. The SVC has been tested successfully in my rack system by replacing the rack's IVC card. So... looking at the GM813 I see no activity on the Address or Data bus. Investigations so far show that the clock signal when viewed at the CPU looks good and that the system is not held at reset nor in a halted state. I have swapped the CPU between this and the rack system to no effect, i.e. the rack system works with the MFB CPU, the issues with the MFB system are the same. I also dumped the Simon ROM successfully and popped RP/M 2.1 into the GM813 for good measure, alas, no change in symptoms. It would be awesome to get this system back to good health, if anyone has any thoughts of how to take this forward, I would really appreciate it. |
11th Jan 2020, 4:34 pm | #300 |
Heptode
Join Date: Aug 2009
Location: Worthing, Sussex, UK.
Posts: 662
|
Re: Gemini 80-Bus System
The GM813 has 64k Ram on it.
Try replacing the MAP80(ram) and the GM811(cpu) card in the rack system with the GM813 card from the MFB system. This should be able to run RP/M as before with the GM832(SVC) or GM812(IVC) Video card. Depending on if this works or not will give you some useful information. You should also be able to try the GM849 from the MFB system as a replacement for the GM829 card in your rack system. This should at least attempt to boot from the floppy disk although you might need a slightly different version of CP/M to work properly. As a personal favour if you get this combo running would you like to run my basic program posted above and post the output so I can complete my MFB system emulation. Best wishes John |