UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Closed Thread
 
Thread Tools
Old 22nd Mar 2018, 4:13 pm   #21
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

One further observation, at the top of the table it shows HEXDUMP 1000, 1800

What is the significance of these numbers?

Regards
Symon.
Philips210 is offline  
Old 22nd Mar 2018, 4:34 pm   #22
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

Quote:
Originally Posted by SiriusHardware View Post
As a matter of interest Symon, which microprocessor does this Elektor project of yours use?
Hi SiriusHardware.

There's no microprocessor in this project, the EPROM just being used for the 'map' of the electronic maze. The Dutch version of the mag has the same project https://archive.org/details/Elektuur245198403Gen
The article starts on page 42 or 24/59 of the pdf.

Regards
Symon
Philips210 is offline  
Old 22nd Mar 2018, 4:55 pm   #23
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Interpreting a hexdump table

That explains why I couldn't recognise any code typical of any familiar microprocessor family. Very interesting.

The 1000, 1800 would usually be the hex FROM and TO start and end addresses from which the code was dumped from the host system originally but then I would expect the addresses at the side of the listing to have that range as well, and they don't, they start at 0000 and increase in steps of 0010H (16 decimal) because each line of the listing has 16 bytes of data in it.

I would suggest just entering the code at address 0000H onwards in your programmer's hex editor, assuming it has one.
SiriusHardware is online now  
Old 22nd Mar 2018, 5:05 pm   #24
duncanlowe
Nonode
 
Join Date: Jan 2016
Location: Stafford, Staffs. UK.
Posts: 2,529
Default Re: Interpreting a hexdump table

This takes me back. I typed the code for a program called Tinymon and put it into an EEPROM to use in my Vic20. Still haven't got round to testing it some 30 plus years later!
duncanlowe is offline  
Old 22nd Mar 2018, 11:27 pm   #25
Argus25
No Longer a Member
 
Join Date: Oct 2016
Location: Maroochydore, Queensland, Australia.
Posts: 2,679
Default Re: Interpreting a hexdump table

Quote:
Originally Posted by Philips210 View Post
There's no microprocessor in this project, the EPROM just being used for the 'map' of the electronic maze.
One of the first ROM based arcade video games using the ROM for storing the Maze image was Atari(Kee Games) arcade TANK from 1974. There were two large pcb's linked by a strap with scores of TTL IC's (it made the arcade Pong pcb from 1972 with 66 TT IC's look small) on each and just the one ROM, again no microprocessor. Unlike Pong it had also advanced to an interlaced scan and had much better TV sync generators.

As I recall the ROM also held images of the Tank too at various rotational angles just one half of it and it was reflected to get the other half. The Tanks could be driven around the maze for combat and the sound effects of the Tank's engines were amazingly realistic, done with some Motorola analog IC's. It was a very power hungry pcb.

It is interesting to see video games with memory, but no microprocessor.
Argus25 is offline  
Old 22nd Mar 2018, 11:48 pm   #26
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Interpreting a hexdump table

I went to that site and noticed that as as well as the PDF version there was also a 'text only' version which is a (not perfect) OCRed version. I cut and pasted the hex dump (only) out of that and have fixed quite a few errors - like "I" or lower case "L" instead of "1", and various characters like "!" which got inserted instead of ":" along with occasional extra or missing spaces, just by using find / replace in a text editor. It helps that the only valid characters are 0-9, A-F and ':' so any character which is not one of those is obviously wrong.

The main problem is the extreme difficulty of distinguishing, even with the human eye, the difference between capital 'B' and figure '8', and I have noticed a few cases where the OCR has decided one way and I think it is the other. In some cases even the crossed '0' has been misidentified as '8'. What this means is that even if a hex file can be generated the end result would still have to be checked byte by byte against a good printout, correcting where necessary.

Symon, which file formats does your programmer support? The least difficult to generate would probably be comma-separated ASCII hex, then plain binary .bin files. Intel Hex or Motorola 'S' would require the addition of extra information to each line, such as the address, the number of bytes in the line and a (calculated) checksum at the end of each line.
SiriusHardware is online now  
Old 23rd Mar 2018, 2:02 pm   #27
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

Quote:
Originally Posted by Argus25 View Post
One of the first ROM based arcade video games using the ROM for storing the Maze image was Atari(Kee Games) arcade TANK from 1974. There were two large pcb's linked by a strap with scores of TTL IC's (it made the arcade Pong pcb from 1972 with 66 TT IC's look small) on each and just the one ROM, again no microprocessor. Unlike Pong it had also advanced to an interlaced scan and had much better TV sync generators.

As I recall the ROM also held images of the Tank too at various rotational angles just one half of it and it was reflected to get the other half. The Tanks could be driven around the maze for combat and the sound effects of the Tank's engines were amazingly realistic, done with some Motorola analog IC's. It was a very power hungry pcb.

It is interesting to see video games with memory, but no microprocessor.
That's very interesting to read Hugo. It must have taken considerable effort designing and developing such circuitry and to put it into production. The original TTL ICs were quite power hungry but seemed to be a very robust technology. Industry standard ICs that can be sourced (in their day) from most countries so component accessibility and repairs should not be a problem.

The Elektor game Elabyrinth isn't actually a video game. It uses a an arrangement of LEDs for the 'display' but is nevertheless an interesting project using an EPROM.

Regards
Symon.
Philips210 is offline  
Old 23rd Mar 2018, 2:59 pm   #28
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

Quote:
Originally Posted by SiriusHardware View Post
Symon, which file formats does your programmer support? The least difficult to generate would probably be comma-separated ASCII hex, then plain binary .bin files. Intel Hex or Motorola 'S' would require the addition of extra information to each line, such as the address, the number of bytes in the line and a (calculated) checksum at the end of each line.
Hi SiriusHardware.

I'm afraid I don't know as I haven't any information on it. I was going to ask if anyone has a user manual for the Stag PP28. This particular unit is also badged RS (as in RS Components formerly Radiospares) with their stock number 300-530 on the front panel no less!

I have also acquired various other EPROM programmers primarily intended for the BBC micro computer. Also a much more up to date and versatile programmer namely a Dataman S4 which I assume should readily connect to any PC.
Thanks for your interest.

Regards
Symon.
Philips210 is offline  
Old 23rd Mar 2018, 3:23 pm   #29
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Interpreting a hexdump table

I can't help you with the PP28 - there is a french chap whose name and website escape me, but he seems to have made it his life's work to archive as much eprom programmer information and software as possible. I would have thought, though, that his would be one of the first resources to come up in any search so maybe he just doesn't have the PP28 covered.

The Dataman S4 is (relatively) modern, but it will need the associated support software and perhaps a specific USB driver for your version of Windows if it is a USB connected version rather than old-school serial port connected.

The reason I asked about file formats is that I (might) be able to create a hex file out of the OCRed text version on that site you linked to. It doesn't really matter though, all I have to do is create one viable version - perhaps a plain binary .bin version - and then use any number of ways to convert it to multiple other file formats, one of which would be loadable into one of your eprom programmers.

As stated previously, the main problem with this approach is that the original OCR process did not pick up the characters 100% perfectly. You would probably have to use human judgement to edit any remaining differences between the original print version and the file version produced from the OCRed text version. Even that might not be as tedious as entering the whole lot by hand. Just award yourself a chocolate biscuit for every 16 lines checked...
SiriusHardware is online now  
Old 23rd Mar 2018, 4:27 pm   #30
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

Hi SiriusHardware.

The OCR process is very useful but as you point out, those zeroes with the diagonal bar can be taken as figure 8. I don't recall Elektor offering a hex or binary file for programming the EPROMs though I may be wrong. Perhaps it was to encourage the constructor to purchase the readily programmed EPROMs.

The I/O facilities on the PP28 are via the RS 232C connector.

Regards
Symon
Philips210 is offline  
Old 23rd Mar 2018, 7:13 pm   #31
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Interpreting a hexdump table

I had a quick look around and information on the PP28 seems rare indeed. The one thing going for it is that, with its keypad and display, you can use it entirely standalone if you absolutely have to.

The aforementioned Frenchman does have some info on the PP39, which is a different looking beast.

http://matthieu.benoit.free.fr/Stag_PP39_programmer.htm

It appears to be supported by non-original software called 'Stagview' which states compatibility with several Stag programmers all with higher model numbers than your PP28 and unfortunately not including your programmer - it might be worth dropping the site owner a message to ask if he thinks it might be comms compatible with the PP28, or even just try it and see.

Your Dataman S4 on the other hand looks a much better prospect - manuals, support software (for DOS and Windows) all miraculously still available on their site - I suggest you grab it all while you still can. The support software for the Dataman will include an on-screen hex editor which will enable you to look at a whole area of data at once - it's much easier to keep track of where you are when you can see a few bytes east and west of the one you are currently checking or editing.

https://www.dataman.com/dataman-s4-resources
SiriusHardware is online now  
Old 23rd Mar 2018, 7:20 pm   #32
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

Thanks again SiriusHardware, much appreciated.

Regards
Symon.
Philips210 is offline  
Old 24th Mar 2018, 1:11 am   #33
Argus25
No Longer a Member
 
Join Date: Oct 2016
Location: Maroochydore, Queensland, Australia.
Posts: 2,679
Default Re: Interpreting a hexdump table

Quote:
Originally Posted by Philips210 View Post
The original TTL ICs were quite power hungry but seemed to be a very robust technology. Industry standard ICs that can be sourced (in their day) from most countries so component accessibility and repairs should not be a problem.
Symon,

This is exactly right and it is the thing I admire most about vintage TTL based video games, you can repair them anywhere in the world and the generic TTL chips are still available (with some exceptions see below).

I have everything for Tank, working PCB's the original monitor, control handles, even the plexglass face with the artwork, the wiring loom and the original coin mechanism all nos. All I'm lacking is the wooden cabinet. But a fellow in Canada sent me the stencils so I just have to have the cabinet manufactured and I will have an NOS arcade Tank from 1974, but it is in the "to do box".

I'm a bit of a fanatic for spare parts and I found for the Tank pcb's I could get every IC except one tricky one, the 8277N otherwise known as a 9328, a type of shift register as I recall. I finally found some in Germany so my spare parts bin for Tank is complete.

I have all the original service documentation for arcade Tank. It was much better than the limited amount of data released by Atari for Pong. It comes with circuit explanations/ descriptions circuit theory and and oscillograms.

In their (Kee games) 1974 technical manual I found the attached paragraph, an odd but frank remark in a technical manual, about the behavior of human beings, somewhat disturbing and it was picked up by video game makers very early in the dawn of the video gaming industry and they could make money out of it.

Later, as you are aware, uP/computer supported video games became very detailed and violent in character and clearly these do have some detrimental effects on the development of young and impressionable minds.

But looking back at the early arcade games like Pong, Asteroids, GranTrak etc, it all seemed so charming and innocent.
Attached Thumbnails
Click image for larger version

Name:	tank.jpg
Views:	98
Size:	64.6 KB
ID:	159824  

Last edited by Argus25; 24th Mar 2018 at 1:20 am. Reason: typo
Argus25 is offline  
Old 24th Mar 2018, 2:42 am   #34
Argus25
No Longer a Member
 
Join Date: Oct 2016
Location: Maroochydore, Queensland, Australia.
Posts: 2,679
Default Re: Interpreting a hexdump table

..I could have mentioned that a lot of the early video game makers decided to go with existing TV or computer monitor technology, rather than custom LED displays as they could use off the shelf CRT TV's/monitors. But quite a few magazine projects used "make your own display screen" with LED's.

For example Atari's arcade Pong used a domestic monochrome TV and they disabled the RF sections and they made use of it as a " Video Monitor" and the audio amp-speaker was used too. Mainly after that, most of the arcade game makers went to industrial CRT monitors, first monochrome like in Tank and then color. And for home use they went to LSI IC's (kind of ruined the fun for 74 series TTL lovers) with RF modulators for home TV's.
Argus25 is offline  
Old 24th Mar 2018, 3:08 pm   #35
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

Hugo

The Tank project sounds very good and it would be great to see some pics as it is being built. Talking of TTL ICs, I have found a couple of 7489 ics in my stock of parts and I was surprised to learn they're actually 64 Bit RAM devices, I was unaware these were part of the TTL family. We tend to think of gates, counters, flip-flops, registers etc but not memory.


Are the PCBs of the plated through hole type? I've found desoldering the ics on this type of board calls for considerable care to avoid damaging the copper foil pads. I remember being told a long time back it's often better to apply a small amount of fresh solder to each joint to assist when using the desoldering braid. It helps the solder to flow better. I like the reliable turned pin IC sockets, although pricey are worth using when building from scratch to prevent any possible damage to the board.

Regards
Symon
Philips210 is offline  
Old 24th Mar 2018, 4:08 pm   #36
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

Hi.

I've been having a look at the Stag PP28 EPROM programmer (see attached pics).

Pic 1 shows the unit with type 2716 EPROM selected and a previously programmed EPROM (not sure where it was originally employed) in the 24 pin ZIF socket.

Pic 2 Gives an overview of the key switches

Pic 3 Indicates the EPROM type on the LED display.

After pressing List, the display shows the address 0000 and the data at this address is 4A as in pic 4. By using the left and right arrow keys, I can go though each address and read the data at that address. Also, I can manually key in a particular address and read the data value.
The upper limit to the address is 07FF as seen in pic 5.

From the above, I have basically worked out how to read the data from a EPROM but my difficulty is working out the procedure for programming one.

From the keyboard switches (pic 2) there's a Fn key Function possibly? I think the In key is for inputting data to the programmer's RAM via the RS 232C link. Likewise the Out key I think will be for outputting the data from the programmer's RAM and possibly the EPROM to a computer via the RS 232C link.

I found the Load key copies the contents of the EPROM and places this in the programmer's RAM.
The Prog key must logically be program but I haven't worked this out just yet.
The List key seems straightforward so no difficulties there.
The Verify key I don't know how this functions but I believe is used in the programming sequence.

The Empty key again I'm not too sure about. One interesting thing about this particular programmer (RS 300-530 Stag PP28) is it's described as a EPROM programmer. The Stag only badged PP28 is described as a EPROM and EEPROM programmer so the ROM is electrically erasable in the latter case. So maybe the Empty key is for clearing the contents of a EEPROM.
The C 'sum key ( check sum? ) again is for programming but I don't know when this is required.

The Edit and Enter keys are again I think used in the programming mode. The Reset key seems to be fairly self explanatory.

One thing I notice is there are four digits in the address which at first doesn't seem right. The 2716 has 11 address lines so only three hex digits would be required, hence 7FF or 111 1111 1111 in binary, being the upper address limit (all '1's). I assume the left hand zero is for other EPROMS that require it.

The next thing to do is try and find the EPROM eraser, an old RS unit lurking somewhere in one of the many boxes out in the garage.
I am pleased that I've got this far but the programming operations will be more involved. If anyone can give me any further guidance then it would be much appreciated. Thanks.

Regards
Symon.
Attached Thumbnails
Click image for larger version

Name:	pp28main.jpg
Views:	88
Size:	77.3 KB
ID:	159837   Click image for larger version

Name:	pp28key.jpg
Views:	83
Size:	82.3 KB
ID:	159838   Click image for larger version

Name:	pp28epromtype.jpg
Views:	89
Size:	69.3 KB
ID:	159839   Click image for larger version

Name:	pp28epromlist.jpg
Views:	92
Size:	73.8 KB
ID:	159840   Click image for larger version

Name:	pp28lastaddr.jpg
Views:	69
Size:	74.1 KB
ID:	159841  

Philips210 is offline  
Old 26th Mar 2018, 12:08 pm   #37
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Interpreting a hexdump table

'Verify' on device programmers traditionally means 'Compare the content of the device with the content of the programmer's RAM buffer and tell me if they match exactly'.

Most often invoked automatically just after a device has been programmed, it can also be used manually any time you want to compare the programmed content of a device with the content of a file which you've loaded into your programmer, or if you want to double or triple check that a device you have just programmed did program correctly.

I've got a preliminary binary version of the labyrinth code put together but It needs to be error checked.
SiriusHardware is online now  
Old 26th Mar 2018, 12:32 pm   #38
GMB
Dekatron
 
GMB's Avatar
 
Join Date: Aug 2003
Location: near Reading (and sometimes Torquay)
Posts: 3,086
Default Re: Interpreting a hexdump table

Proper programmers will distinguish between a crude "verify" of just reading the data and comparing, from "program verify" which involves reading the data back using different applied voltages. The "program verify" mode can (depending on chip type) be done quite elaborately to actually measure how close to death the EPROM is, i.e. how much life remains in it.
The point is that it distinguishes between "just managed to work today" from "likely to still be working tomorrow".
GMB is online now  
Old 27th Mar 2018, 8:28 pm   #39
Philips210
Nonode
 
Join Date: May 2007
Location: Redruth, Cornwall, UK.
Posts: 2,562
Default Re: Interpreting a hexdump table

Quote:
Originally Posted by SiriusHardware View Post
I've got a preliminary binary version of the labyrinth code put together but It needs to be error checked.
Hi SiriusHardware.

Thanks for taking the trouble to do this.

I just found a follow-up to the Elektor Elabyrinth project. In the January 1985 issue under 'missing link', it states "The last address and data (800: FF) in the hexdump in table 1 should be deleted."

Regards
Symon.
Philips210 is offline  
Old 27th Mar 2018, 9:57 pm   #40
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,482
Default Re: Interpreting a hexdump table

Yes, I worked that out.

In a 2716 as used in that project, the address range is 000-7FF, so address 800 does not exist.

I have checked through exactly half of the generated code so far against a large A3 sized printout of the original dump in the article. I've found several more recurring errors including the occasional 'S' where '5' should be - that was caught by the ASCII hex to raw binary conversion process because 'S' is not a valid hex character - and also a leading 'D' in an ASCII byte was sometimes mistaken for '0' at the original OCR stage. Unfortunately both 'D' and '0' are valid hex digits so I'm having to root those ones out manually.

I'm assuming I can take my time to do the rest, as I don't imagine you'll have the hardware built in the next five minutes.

If, by the time I do this, you still don't have the means to read a code file into one of your programmers and then program it into an eprom, I could of course send it to you -in an eprom-. You could then read it out into your PP28 and step through it checking my (hopefully correct) version against your own printout.

If you were happy that it was correct you could just use the eprom as-is, but if you found that further errors needed correcting you could change the offending data in the programmer's RAM and then program the amended code into another blank 2716.

As far as the ability to load and use code files is concerned, the Dataman is still the better bet, and I would urge you to try installing the PC support software for that and have a go with it - Programmers driven from a PC are always far easier to use than standalone programmers.
SiriusHardware is online now  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 2:23 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.