Tim's Virtuality Thread
- Thread starter trm
- Start date
Last weekend I picked up the VR boxes from Cyclo who was suffering badly from not-enough-space-itis.
Details
I didn't get much chance to play until late in the week so decided to start work on the Amigas as I know these reasonably well. Each chassis has an A3000/030 at the bottom with fly-leads coming from each port. These connect into a custom PCB mounted in the top of the case. Each chassis has a pair of TI-DSP based boards stuffed with ZIP VRAM to render the 'advanced' graphics. Finally, mounted underneath the lid is another custom PCB which handles the XYZ calculations from the hall effect sensors.
This board has connectors for the headsets which are based on an early EPSON (DSTN?) LCD which is logically split in two and viewed through some incredibly complex optics. Also linked into the top board is a joystick which uses hall effect sensors to provide XYZ placement. There are two resin dipped blocks which need to be hung from the ceiling and are fed from the chassis to provide the XYZ signals.
We knew from early exploration that the NiCads had leaked, oozing alkaline electrolyte over the board. It was localised to the rear left quandant, but was pretty nasty. We neutralised this with an acid and made lots of NaCl
Power-up
The chassis has a flicker fixer installed which in theory will present a 31.5K signal on the DSUB15. I powered up, heard disk spinup but saw nothing on the VGA screen.
I then scoped out the DSUB23 looking for a 15K signal and saw a working clock! I made a lead to wire this into my vintage 1084S and applied power. I got the black, grey then white screen changes much known to Amiga owners! Unfortunately the boot didn't proceed past this point even if left for some time.
I wasn't sure if this was due to poor SCSI termination (I removed the CDROM which was terminating the bus), lack of a keyboard (I don't have one) or because the boot config held using the RTC battery was gone (I'd removed the battery).
After stripping the machine to the bare essentials I still had no boot so started scoping the custom chip bus. This showed a worrying lack of signals other than a few Vcc and GND. I wasn't able to get to the CPU bus yet. After an hour of fibre glass pencil I removed most of the salt and oxide layer but still didn't see much hopeful. So I then totally stripped the chassis and got it under a magnifying glass.
Dead Hardware
Closer examination showed the following (pics to be uploaded later):
Dead:
74HC04N @ U477
74ALS74AN @ U480
48-pin socket @ U400 (Paula)
48-pin socket @ U450 (Denise)
18-pin socket @ U190
Dodgy:
Paula and Denise custom ICs. The legs show corrosion almost to the chip body, so I don't know whether there has been ingress.
68pin PLCC socket @ U478 (Amber)
86pin PLCC socket @ U205 (Fat Agnus)
Whilst this was going on I posted some wanted ads on Amiga boards, begged foreign ebay sellers to post to me and scrounged around for any salvageable bits.
Fix Plan
I've now split my plans into three threads.
1. Restoration of existing motherboard. I lifted the dead DIP sockets, pulled the corroded chips and will shortly be fitting new sockets and ICs.
2. Sourcing a new A3000/030 chassis. I've found a working but bare A3000D in Europe for 50 euros which is on its way. I'm hoping to use the customs and RAM from my 'dead' board on the new mobo. This is currently my best option as it has the same CPU and chipset as the existing machines.
3. Sourcing a fully working (and loaded) A4000. I managed to find a 68030 @ 30 MHz which is identical to the extand A3000, but it's running OS 3/Workbench 3 which is a later version to the OS 2.04 / WB 2.04 in the current system. I'm hoping the app devs used a decent compiler that followed the hardware guidelines after experiencing problems moving from OS 1.3 to OS 2.04 and finding very little worked. If not it looks like I'm porting the game exe to AGA graphics chipset It's been a while since I had to ReSource a huge program, and it's not #1 on my list of fun things.
Software
Packaged with the hardware were a handful CDRs. Looking through these show that 4 are for the later PC versions but 2 are unreadable. The labels suggest these last two contain the Amiga version. I'm pretty sure the early Amiga CD-ROM didn't use ISO9660, so I'm hoping that the disks have a custom format rather than having unreadable bitrot.
I'm going to try a raw disk reader under Linux to make images which I can then mount in WinUAE. If I get no luck I've got an A570 CD-ROM drive which I can plug into my old A500 (Assuming it's not got clock battery leak too) to rip the software. Worst case I'll dump an ISO on the A500/A570 and then transfer it to a PC via a 115k serial link
. I believe the CDRs should be mixed mode with a few CDDA audio tracks (BGM) and a data partition for the software.
Risks and Mitigation
So, my current risks (and mitigation) are:
1. The SCSI hard disks might be dead. If both are screwed then I have no software, no means of finding any and am dead in the water.
2. I end up using A4000s and find the software fails because of hardware incompatibilities, most likely due to the AGA chipset. I can try to disassemble the code, get it back to 68030 machine language and patch it to work with the AGA chipset. My chance of success depends on how well the software was coded - using the API libraries gives me a much better chance of fixing by coding a library hook (kind of a DLL hook). Some of these fixes are trivial - not using the upper byte of pointers to store data, modifying illegal custom chip addresses. Others aren't so trivial - new blitter calling methods, relying on old hardware bugs etc. I really don't want to have to relocate the whole code to make room for my hacks.
3. Dead visettes (the headset unit). My chance of getting replacement compatible LCDs is about the same as acquiring the software!
So that's where I'm at currently. I'm hoping to have fitted new sockets and made an attempt at booting the board. I'll edit this and upload pictures too.
cheers,
tim
Details
I didn't get much chance to play until late in the week so decided to start work on the Amigas as I know these reasonably well. Each chassis has an A3000/030 at the bottom with fly-leads coming from each port. These connect into a custom PCB mounted in the top of the case. Each chassis has a pair of TI-DSP based boards stuffed with ZIP VRAM to render the 'advanced' graphics. Finally, mounted underneath the lid is another custom PCB which handles the XYZ calculations from the hall effect sensors.
This board has connectors for the headsets which are based on an early EPSON (DSTN?) LCD which is logically split in two and viewed through some incredibly complex optics. Also linked into the top board is a joystick which uses hall effect sensors to provide XYZ placement. There are two resin dipped blocks which need to be hung from the ceiling and are fed from the chassis to provide the XYZ signals.
We knew from early exploration that the NiCads had leaked, oozing alkaline electrolyte over the board. It was localised to the rear left quandant, but was pretty nasty. We neutralised this with an acid and made lots of NaCl
Power-up
The chassis has a flicker fixer installed which in theory will present a 31.5K signal on the DSUB15. I powered up, heard disk spinup but saw nothing on the VGA screen.
I then scoped out the DSUB23 looking for a 15K signal and saw a working clock! I made a lead to wire this into my vintage 1084S and applied power. I got the black, grey then white screen changes much known to Amiga owners! Unfortunately the boot didn't proceed past this point even if left for some time.
I wasn't sure if this was due to poor SCSI termination (I removed the CDROM which was terminating the bus), lack of a keyboard (I don't have one) or because the boot config held using the RTC battery was gone (I'd removed the battery).
After stripping the machine to the bare essentials I still had no boot so started scoping the custom chip bus. This showed a worrying lack of signals other than a few Vcc and GND. I wasn't able to get to the CPU bus yet. After an hour of fibre glass pencil I removed most of the salt and oxide layer but still didn't see much hopeful. So I then totally stripped the chassis and got it under a magnifying glass.
Dead Hardware
Closer examination showed the following (pics to be uploaded later):
Dead:
74HC04N @ U477
74ALS74AN @ U480
48-pin socket @ U400 (Paula)
48-pin socket @ U450 (Denise)
18-pin socket @ U190
Dodgy:
Paula and Denise custom ICs. The legs show corrosion almost to the chip body, so I don't know whether there has been ingress.
68pin PLCC socket @ U478 (Amber)
86pin PLCC socket @ U205 (Fat Agnus)
Whilst this was going on I posted some wanted ads on Amiga boards, begged foreign ebay sellers to post to me and scrounged around for any salvageable bits.
Fix Plan
I've now split my plans into three threads.
1. Restoration of existing motherboard. I lifted the dead DIP sockets, pulled the corroded chips and will shortly be fitting new sockets and ICs.
2. Sourcing a new A3000/030 chassis. I've found a working but bare A3000D in Europe for 50 euros which is on its way. I'm hoping to use the customs and RAM from my 'dead' board on the new mobo. This is currently my best option as it has the same CPU and chipset as the existing machines.
3. Sourcing a fully working (and loaded) A4000. I managed to find a 68030 @ 30 MHz which is identical to the extand A3000, but it's running OS 3/Workbench 3 which is a later version to the OS 2.04 / WB 2.04 in the current system. I'm hoping the app devs used a decent compiler that followed the hardware guidelines after experiencing problems moving from OS 1.3 to OS 2.04 and finding very little worked. If not it looks like I'm porting the game exe to AGA graphics chipset
It's been a while since I had to ReSource a huge program, and it's not #1 on my list of fun things.Software
Packaged with the hardware were a handful CDRs. Looking through these show that 4 are for the later PC versions but 2 are unreadable. The labels suggest these last two contain the Amiga version. I'm pretty sure the early Amiga CD-ROM didn't use ISO9660, so I'm hoping that the disks have a custom format rather than having unreadable bitrot.
I'm going to try a raw disk reader under Linux to make images which I can then mount in WinUAE. If I get no luck I've got an A570 CD-ROM drive which I can plug into my old A500 (Assuming it's not got clock battery leak too) to rip the software. Worst case I'll dump an ISO on the A500/A570 and then transfer it to a PC via a 115k serial link
Risks and Mitigation
So, my current risks (and mitigation) are:
1. The SCSI hard disks might be dead. If both are screwed then I have no software, no means of finding any and am dead in the water.
2. I end up using A4000s and find the software fails because of hardware incompatibilities, most likely due to the AGA chipset. I can try to disassemble the code, get it back to 68030 machine language and patch it to work with the AGA chipset. My chance of success depends on how well the software was coded - using the API libraries gives me a much better chance of fixing by coding a library hook (kind of a DLL hook). Some of these fixes are trivial - not using the upper byte of pointers to store data, modifying illegal custom chip addresses. Others aren't so trivial - new blitter calling methods, relying on old hardware bugs etc. I really don't want to have to relocate the whole code to make room for my hacks.
3. Dead visettes (the headset unit). My chance of getting replacement compatible LCDs is about the same as acquiring the software!
So that's where I'm at currently. I'm hoping to have fitted new sockets and made an attempt at booting the board. I'll edit this and upload pictures too.
cheers,
tim
w00t! After replacing the grody sockets I still wasn't getting a proper boot. So I decided to use the schematics and some very high-res photos I took when it was desocketed and trace the pins for the two customs most badly affected by the battery leak.
Half way through and I'm slightly despairing and I find a bit down in the bus between Denise and Paula!
I'm going to check the rest of the pins on this custom (Paula) as it was directly next to the leaky battery. Ten more to go and I can resolder the duff track and power it up.
Half way through and I'm slightly despairing and I find a bit down in the bus between Denise and Paula!
I'm going to check the rest of the pins on this custom (Paula) as it was directly next to the leaky battery. Ten more to go and I can resolder the duff track and power it up.
Well, I was pretty happy when I found a pair of missing tracks. I fixed them and powered up to be greeted by a new crash - like a watchdog was kicking in and cycling the machine.
At this point a pic of the acid damage might be helpful to give some idea of what I'm doing.
By this photo I'd already removed the 48 pin sockets for Denise and Paula. The components marked in red are porked too so have come off.
During this I found a couple more tracks which were dead. It looks as though the electrolyte converged on the pins and then worked around the thru-hole. It then eat through the track where it met the thru, leaving a microscopic yet definitely present gap. It's almost impossible to see by eye, but they are definitely not connected.
I've wired in new tracks using Kynar wire but it's becoming a rats nest now. I might try silver deposit pens to bridge the gap between thru and track but am concerned that subsequent soldering might mess this up.
Plan B is progressing quite well. I took delivery today of a full Amiga 4000 which will be a test-bed for the Amiga cards. I'm also going to try dumping the original SCSI disk using WinUAE so I can boot it on the A4000. If this works and the cards are OK then my temporary measure will be to boot the A4k off CF-IDE.
I've also got an A3000 mobo in the post and am close to buying a pair of working A3000 desktops, so I could be scrapping the eroded boards and keeping them for parts. By the way, if anybody can suggest how to ID the yellow corroded trimmer in the above pic - please shout out.
At this point a pic of the acid damage might be helpful to give some idea of what I'm doing.
By this photo I'd already removed the 48 pin sockets for Denise and Paula. The components marked in red are porked too so have come off.
During this I found a couple more tracks which were dead. It looks as though the electrolyte converged on the pins and then worked around the thru-hole. It then eat through the track where it met the thru, leaving a microscopic yet definitely present gap. It's almost impossible to see by eye, but they are definitely not connected.
I've wired in new tracks using Kynar wire but it's becoming a rats nest now. I might try silver deposit pens to bridge the gap between thru and track but am concerned that subsequent soldering might mess this up.
Plan B is progressing quite well. I took delivery today of a full Amiga 4000 which will be a test-bed for the Amiga cards. I'm also going to try dumping the original SCSI disk using WinUAE so I can boot it on the A4000. If this works and the cards are OK then my temporary measure will be to boot the A4k off CF-IDE.
I've also got an A3000 mobo in the post and am close to buying a pair of working A3000 desktops, so I could be scrapping the eroded boards and keeping them for parts. By the way, if anybody can suggest how to ID the yellow corroded trimmer in the above pic - please shout out.
Thanks to smythe for pointing the auctions out; I just won two auctions, one for a full working A3000D and another for a working A3000 motherboard. So that's another 450 euros on top of last week's A4000 and the original units. I reckon it's up to about £1k now.
Better hope the f**king disks have some actual data on them!
Better hope the f**king disks have some actual data on them!
Well, I finally attached the SCSI disks to my PC, booted Linux and tried to mount them using the AFFS. Each time I got a vague error message about the super block
I decided to dump the disks to see what I could find and perhaps mount it under the windows Amiga emulator - WinUAE, but on both disks I get random SCSI sense failures. Using dd to dump I can get between 0 bytes and 10 MB off each of the disks before I get IO errors which is a bit disappointing.
Looking through the dumps I see all the data I'd expect though and the basic disk structure appears intact. I'm not yet 100% convinced that the disks are porked; it may be my SCSI controller being a bit too whizzy and not fully backwards compatible, or it could be some SCSI options within the Linux drivers.
I think my next step is to wait for the working A3000 to turn up, hopefully this week. I can set the disk jumpers to hardware read only and try booting to see what I can get. Unless I can buy a SCSI card for my A4000 before then
I decided to dump the disks to see what I could find and perhaps mount it under the windows Amiga emulator - WinUAE, but on both disks I get random SCSI sense failures. Using dd to dump I can get between 0 bytes and 10 MB off each of the disks before I get IO errors which is a bit disappointing.
Looking through the dumps I see all the data I'd expect though and the basic disk structure appears intact. I'm not yet 100% convinced that the disks are porked; it may be my SCSI controller being a bit too whizzy and not fully backwards compatible, or it could be some SCSI options within the Linux drivers.
I think my next step is to wait for the working A3000 to turn up, hopefully this week. I can set the disk jumpers to hardware read only and try booting to see what I can get. Unless I can buy a SCSI card for my A4000 before then
w00t. One of my recent A3000 purchases just arrived. Not bad from France and posted on Monday. Though for 60 euros shipping I had expected something special; maybe there are dancing girls inside...
Either a joyful update later as I find the disks work ok, or a suicidal post advertising a load of Amigas and VR kit to the first dude who turns up.
Either a joyful update later as I find the disks work ok, or a suicidal post advertising a load of Amigas and VR kit to the first dude who turns up.
w0000000t x eleventy.
The disks are fine. In fact, they are better than fine - they are f**king superb! Between the two disks they have all the games I knew of and more. I've booted one set of the TI gfx cards and they are good too.
At the moment all the fun has been paused whilst I figure out a backup solution for the disks though. I forgot to report back as I was so excited I spent all night doing a shuffle.
The disks are fine. In fact, they are better than fine - they are f**king superb! Between the two disks they have all the games I knew of and more. I've booted one set of the TI gfx cards and they are good too.
At the moment all the fun has been paused whilst I figure out a backup solution for the disks though. I forgot to report back as I was so excited I spent all night doing a shuffle.
The components are below and their health is listed too:
2 Amiga chassis: one working, mobo delivery on Friday for second
2 pair TI DSP GFX cards: one pair tested, one pair needs minor repair
2 tracker pcb: does 3d motion from controller. neither tested
2 interface pcb: converts power, muxs amiga outputs, one defo dead, other unknown. no visible faults
masses of interface cabling: some has been really battered, all needs checking
2 waist packs: feels like it contains lead acid batteries. runs from units to headset. both untested
2 headsets: look intact, both untested
2 network cards: look OK but need to find my old 10-B-2 wiring.
My longer term plan and holy grail is to find the SDK for this. I'm going to dump some of the executables at the weekend to see if they have debugging symbols. I'm reasonably confident they will; of the games I have, there are multiple versions of each with close dates so it looks like dev was pretty healthy so am hoping they had debug symbols left in for ease of troubleshooting. I have found some programming material for the DSP cards and have been in touch with Jed Margolin about them (Atari used the same gear in quite a few games). I'd love to write my own game to see how far I can push the gear.
Finding some other owners would be very cool too. I'm hoping to get on the first page of google for Virtuality soon so hopefully I'll get some contacts.
Assuming these end up working I'll be bringing them along to a meet or two. Poking around last night I found confirmation that some of the games do support multi-player through the local LAN. I think it'll be pretty good fun to play, but knowing that we can do multiplayer I'm even more excited
Then there are some plans to replace the LCDs to give a nicer experience. Higher res with super-sampling should get rid of some of the nausea problems.
2 Amiga chassis: one working, mobo delivery on Friday for second
2 pair TI DSP GFX cards: one pair tested, one pair needs minor repair
2 tracker pcb: does 3d motion from controller. neither tested
2 interface pcb: converts power, muxs amiga outputs, one defo dead, other unknown. no visible faults
masses of interface cabling: some has been really battered, all needs checking
2 waist packs: feels like it contains lead acid batteries. runs from units to headset. both untested
2 headsets: look intact, both untested
2 network cards: look OK but need to find my old 10-B-2 wiring.
My longer term plan and holy grail is to find the SDK for this. I'm going to dump some of the executables at the weekend to see if they have debugging symbols. I'm reasonably confident they will; of the games I have, there are multiple versions of each with close dates so it looks like dev was pretty healthy so am hoping they had debug symbols left in for ease of troubleshooting. I have found some programming material for the DSP cards and have been in touch with Jed Margolin about them (Atari used the same gear in quite a few games). I'd love to write my own game to see how far I can push the gear.
Finding some other owners would be very cool too. I'm hoping to get on the first page of google for Virtuality soon so hopefully I'll get some contacts.
Assuming these end up working I'll be bringing them along to a meet or two. Poking around last night I found confirmation that some of the games do support multi-player through the local LAN. I think it'll be pretty good fun to play, but knowing that we can do multiplayer I'm even more excited
Then there are some plans to replace the LCDs to give a nicer experience. Higher res with super-sampling should get rid of some of the nausea problems.
Now I can mount the images on my PC I have had a quick look at the games.
Disk1
Battlesphere
Nightmare
VTOL
WalkerII
ets2.6 (Engineering & config tool)
Disk2
grid (maybe a dupe of gridbusters)
Gridbusters
LC (???)
LegendQuest
LegendQuest2 (not sure if a new version or a copy)
Nightmare
rock (no idea yet)
sark (same)
bobnet (think it's the networking config)
bubble (no idea - would be nice if it was VR Bubble Bobble)
ets2.6 (newer version of the setup tool)
The disk images will be online shortly in case anybody fancies having a poke with WinUAE. URL to follow when they've finished uploading.
Disk1
Battlesphere
Nightmare
VTOL
WalkerII
ets2.6 (Engineering & config tool)
Disk2
grid (maybe a dupe of gridbusters)
Gridbusters
LC (???)
LegendQuest
LegendQuest2 (not sure if a new version or a copy)
Nightmare
rock (no idea yet)
sark (same)
bobnet (think it's the networking config)
bubble (no idea - would be nice if it was VR Bubble Bobble)
ets2.6 (newer version of the setup tool)
The disk images will be online shortly in case anybody fancies having a poke with WinUAE. URL to follow when they've finished uploading.
Links to ZIP files of the individual partitions -
http://lois.ultrax.org/trmatthe/vr/box1-partitions.zip &
http://lois.ultrax.org/trmatthe/vr/box2-partitions.zip
http://lois.ultrax.org/trmatthe/vr/box1-whole-disk.zip &
http://lois.ultrax.org/trmatthe/vr/box2-whole-disk.zip
Each disk has 3 partitions: WB_1.3:, WB_2.0: and WORK: with the interesting stuff on WORK:
The -partitions.zip are dumps of each partition individually. The -whole-disk.zip is the whole 52MB (box2) and 104MB (box1) disk image.
These have all been dumped three times with a diff run between the copies to determine identical-ness.
trm2013-01-29 13:59:38
http://lois.ultrax.org/trmatthe/vr/box1-partitions.zip &
http://lois.ultrax.org/trmatthe/vr/box2-partitions.zip
http://lois.ultrax.org/trmatthe/vr/box1-whole-disk.zip &
http://lois.ultrax.org/trmatthe/vr/box2-whole-disk.zip
Each disk has 3 partitions: WB_1.3:, WB_2.0: and WORK: with the interesting stuff on WORK:
The -partitions.zip are dumps of each partition individually. The -whole-disk.zip is the whole 52MB (box2) and 104MB (box1) disk image.
These have all been dumped three times with a diff run between the copies to determine identical-ness.
trm2013-01-29 13:59:38
If you want to browse these images you can mount them in WinUAE, or as via loopback under Linux. To do so in WinUAE you need to go into the config options for your virtual Amiga and add these as hardfiles.
Click on Harddrives in the config view.
Click Add Hardfile.
In the Settings window, click ... button against Path and browse to hardfile. Set the display filter to *.*. Add the image file. Tick Bootable flag.
You're done! You will get better results with the full disk image as it has all 3 partitions in one. The source machine is:
A3000, 68030/25, 1 MB Chip, 4 MB Fast, Full ECS.
A lot of the stuff craps out which isn't surprising as it's looking for hardware that isn't present, but there are loads of samples, pics and other files to examine.
Click on Harddrives in the config view.
Click Add Hardfile.
In the Settings window, click ... button against Path and browse to hardfile. Set the display filter to *.*. Add the image file. Tick Bootable flag.
You're done! You will get better results with the full disk image as it has all 3 partitions in one. The source machine is:
A3000, 68030/25, 1 MB Chip, 4 MB Fast, Full ECS.
A lot of the stuff craps out which isn't surprising as it's looking for hardware that isn't present, but there are loads of samples, pics and other files to examine.
More info on the TI cards.
TMS34082AGC-32 (ceramic PGA) and TMS 34020GBL-32 (ceramic PGA w/ gold top)
Each unit has a pair of cards wired for stereo operation. There is a small cable link next to the oscillator which syncs the clocks; stereo mode has master/slave config. You can enable mono by unlinking the cables and dropping in an osc.
TMS34082AGC-32 (ceramic PGA) and TMS 34020GBL-32 (ceramic PGA w/ gold top)
Each unit has a pair of cards wired for stereo operation. There is a small cable link next to the oscillator which syncs the clocks; stereo mode has master/slave config. You can enable mono by unlinking the cables and dropping in an osc.
started delving into the headset a bit more after the last disappointment and figured I'd look at the power feed. The Visette needs 9VDC to power the LCD and upon checking the 24 way connector I couldn't see this. Cue much laborious derivation of a schematic (no schems supplied unfortunately) and I found a fault with a SMPSU which provides part of the power.
I fixed this and was really pleased to see all the expected voltages (I was missing another pair too) so I hastily reassembled the stack. And now the Amiga won't boot. f**k it!
So my next task is to strip it all down again and sort that out. I'm hoping it's not one of the expansion cards gone bad. With any luck it'll just be a motherboard or something, of which I have a stash
Updates to come when I can find some time to play.
I fixed this and was really pleased to see all the expected voltages (I was missing another pair too) so I hastily reassembled the stack. And now the Amiga won't boot. f**k it!
So my next task is to strip it all down again and sort that out. I'm hoping it's not one of the expansion cards gone bad. With any luck it'll just be a motherboard or something, of which I have a stash
Updates to come when I can find some time to play.
OK. Time to bring this back up to date. This is all coming from my recollection of where I got to and what I found so may be revised later when I get hands-on again and have real data instead of years-old memory.
The power boards had some overly complex setup that used a solid state relay to switch power in; ISTR I figured they did this to stop images flickering up on the display during power/boot-up. These were driven by the Amiga's serial or parallel port and caused me no end of hassle. I believe I ended up deciding that a few rug patterns on boot wouldn't be a major problem so I wired around these with some switches.
Still nada on the Visette display. I created a power frankenloom to provide power from normal benchtop variable supplies to completely cut out the "let's over-engineer a cool solution so we have software and hardware points of failure" and finally got some illumination in the Visette but no game image.
Whilst following that path I also started hacking up a system so I could take the Visette feed and send it to a monitor to rule out the Visette interface/wiring/belt pack/displays. I don't recall how that ended - I suspect not well otherwise I'm sure it'd be etched as a winning memory - so I'm going to hunt for the video frankenloom as my first priority when I resume work on this. I just want to see some badly shaded low-poly count blobs!
If anybody wants to poke around the disk images, please feel free. I have a WinUAE image somewhere running ReSource from when I started to take the game code to pieces. I'll see if I can snarf this and get it online too. I don't ever recall having problems starting the games up, I just couldn't see any output from the TI cards so I'm not sure what the situation is with regard to key disks or the like. Nothing ReSource & DevPac can't fix I'm sure.
The power boards had some overly complex setup that used a solid state relay to switch power in; ISTR I figured they did this to stop images flickering up on the display during power/boot-up. These were driven by the Amiga's serial or parallel port and caused me no end of hassle. I believe I ended up deciding that a few rug patterns on boot wouldn't be a major problem so I wired around these with some switches.
Still nada on the Visette display. I created a power frankenloom to provide power from normal benchtop variable supplies to completely cut out the "let's over-engineer a cool solution so we have software and hardware points of failure" and finally got some illumination in the Visette but no game image.
Whilst following that path I also started hacking up a system so I could take the Visette feed and send it to a monitor to rule out the Visette interface/wiring/belt pack/displays. I don't recall how that ended - I suspect not well otherwise I'm sure it'd be etched as a winning memory - so I'm going to hunt for the video frankenloom as my first priority when I resume work on this. I just want to see some badly shaded low-poly count blobs!
If anybody wants to poke around the disk images, please feel free. I have a WinUAE image somewhere running ReSource from when I started to take the game code to pieces. I'll see if I can snarf this and get it online too. I don't ever recall having problems starting the games up, I just couldn't see any output from the TI cards so I'm not sure what the situation is with regard to key disks or the like. Nothing ReSource & DevPac can't fix I'm sure.
Hi Tim,
Is that an old post or new one?. I can help with the visette problem as I worked on mine to get it going and I found lots out about the system. I am currently working on a wiring diagram for the stand up machine. I should have it done by end of week.
Just a note, you mention 9v for the visette, but I guess you read that in the manual?, well I found that it's wrong on my system. It's only 5v, as there is a 5v regulator feeding it.
Let me know if I can help you more, and I also hope you can help me with games for mine.
Simon
Is that an old post or new one?. I can help with the visette problem as I worked on mine to get it going and I found lots out about the system. I am currently working on a wiring diagram for the stand up machine. I should have it done by end of week.
Just a note, you mention 9v for the visette, but I guess you read that in the manual?, well I found that it's wrong on my system. It's only 5v, as there is a 5v regulator feeding it.
Let me know if I can help you more, and I also hope you can help me with games for mine.
Simon
Hiya. All of the posts above can be taken as old pretty much. My last post was a "top of my head, where I left it at" I wrote after collating the rest from 2009-2010 IIRC but it was done without digging through my notes so it's truthyness may be less than 100% due to the amount of time that's passed.
The 9VDC versus 5VDC rings a bell now you mention it. I know I worked to derive my own schematics as the hardware never really matched up with the snippets of info I did have, and I definitely remember having to replace one or more of the 5V regs on the top power board as it was rather tricky to get to due to some post-factory bodge/mod. I followed the Visette paths back from the connector so would have likely hit the 5V regs and realised it was a documentation error.
Any wiring diagram you have would be greatly received. I have an A4 ring binder with notes, sketches and other bits of "this might be useful later on" info, and I did number and label all connectors before packing it away but I know getting the system to boot will be hard enough without wondering if I'm missing a crucial ancillary connector.
Have you seen my reply in your games thread where I link to the HDD images from my systems? It's also the 3rd or 4th post in this thread. I just booted one of my WinUAE systems to see if I can extract the game directories into an LHA to make it a bit easier for people to transport the game exes to a working Virtuality so we can get some idea if they'll run.
It's a great result having so many (relatively speaking) Virtuality owners in one place - it's certainly prompted me to divert some time back to my systems and see if I can get them up and running and get terminal eye strain
The 9VDC versus 5VDC rings a bell now you mention it. I know I worked to derive my own schematics as the hardware never really matched up with the snippets of info I did have, and I definitely remember having to replace one or more of the 5V regs on the top power board as it was rather tricky to get to due to some post-factory bodge/mod. I followed the Visette paths back from the connector so would have likely hit the 5V regs and realised it was a documentation error.
Any wiring diagram you have would be greatly received. I have an A4 ring binder with notes, sketches and other bits of "this might be useful later on" info, and I did number and label all connectors before packing it away but I know getting the system to boot will be hard enough without wondering if I'm missing a crucial ancillary connector.
Have you seen my reply in your games thread where I link to the HDD images from my systems? It's also the 3rd or 4th post in this thread. I just booted one of my WinUAE systems to see if I can extract the game directories into an LHA to make it a bit easier for people to transport the game exes to a working Virtuality so we can get some idea if they'll run.
It's a great result having so many (relatively speaking) Virtuality owners in one place - it's certainly prompted me to divert some time back to my systems and see if I can get them up and running and get terminal eye strain