...I used to program 32-bit ARM and they were quite nice to program in assembler before they went to their C optimized...
I don't follow that. The ARM, well the original ARM, was a RISC processor. The whole point of RISC is to be compiler friendly. Implement instructions that compilers can generate and are commonly used. Skip all the obscure instructions only a human programmer might want.
At a bit of a stretch I might claim the ARM was a 6502 variant. ACORN was using 6502 but wanted to go 32 bits whilst keeping that kind of simplicity, so they designed the ARM.
6809 is my favorite 8 bitter, 6502 second. Two extremes. 6809 is beautiful, and a total beast. 6502 is simple, lean, and has just enough. I did them 6502 first, then 6809. Holy cow! Had it been the reverse, I know I would have been spoiled.
Some targets are harder than others. But, if you drill down and stick with one long enough to get a couple respectable programs done, you will have accomplished a lot of the hard work.
And, when you pick your next target, know you will get a lot more done.
As much as I love PASM, it too is very beautiful, I do not feel it is important as a first target. Don't get me wrong here. It is just fine. Someone learning ASM is a good thing, no matter the CPU. But, one could get spoiled, that's all.
Honestly, that first target should be a CPU that you really want and need to accomplish something on.
That drive really helps. Each little thing done is meaningful and motivating. When you build on those early bits, maybe recoding them a little wiser, it is pretty great to see whatever it is happening at speed, or in some cases, just happening at all! (Often ASM is what makes the impossible, possible.)
6809 was my first real assembler experience. Loved it.
Loved it even more when I subsequently had to work with the Intel 8085 then 8086. A painful step backwards.
We had done some assembler in Technical College but it was via a simulator running on some far away, telephone connected, main frame. I enjoyed that more that the BASIC we used for most of that CS course.
The 68705 has a nice regular instruction set. It's an 8-bit single chip.
But I prefer the Prop P1. Even tho it's 32-bit, I think it's the easiest to learn by far! Regular instruction set, no accumulators, no interrupts, etc.
A trend we all thought would continue with the 68000.
Sadly the IBM PC with it's abomination of the Intel 8086 architecture blew that away.
Interestingly the year before the IBM PC was launched I was working with a very smart young CS graduate from Cambridge. We were building that 6809 processor board that I cut my assembly language programming teeth on.
One day he was expounding on the history of computing and made the claim that IBM has always held back progress in computing by at least ten years. I shrugged it off as I had no idea about such things.
Sure enough, the following year IBM gave us the PC and PC-DOS. That meant there was a 10 year delay between the 32 bit Intel 386 processor coming out (1985) and a 32 bit operating system for the masses (1998).
A trend we all thought would continue with the 68000.
Sadly the IBM PC with it's abomination of the Intel 8086 architecture blew that away.
Interestingly the year before the IBM PC was launched I was working with a very smart young CS graduate from Cambridge. We were building that 6809 processor board that I cut my assembly language programming teeth on.
One day he was expounding on the history of computing and made the claim that IBM has always held back progress in computing by at least ten years. I shrugged it off as I had no idea about such things.
Sure enough, the following year IBM gave us the PC and PC-DOS. That meant there was a 10 year delay between the 32 bit Intel 386 processor coming out (1985) and a 32 bit operating system for the masses (1998).
That young guy was so right!
He certainly was right, but lets not forget that Intel and Microsoft also did their parts as well.
Man oh man, how many of us hated on x86! I am tinkering with 8085 right now too.
You are going to love my latest electronics archaeology acquisition then:
That is a Scandinavian traffic light controller CPU card from the early 1980's. Made by Ericsson.
It has an NEC V20 processor on it. The V20 was go faster clone of the Intel 8086 with a really weirdo feature, it has a mode where it runs the 8080 instruction set. You can switch between 8086 and 8080 on the fly.
@kwinn
...lets not forget that Intel and Microsoft also did their parts as well.
Indeed they did. However both Intel an MS were fly by night start ups at the time that nobody had ever heard of. At least compared to IBM which had dominate the computing landscape for decades.
There was a lot of face palming going on among the engineers around me the day the first IBM PC arrived in the company and they opened it up for a look see. I was in the signal processing group of the old Marconi Radar Company at the time. Those guys had been designing 16 bit processors for a long time so I took their opinions seriously.
I guess it could have been worse. Instead of hurriedly slapping together the 8086 PC, IBM could have come up with their own architecture and gained a lock on the personal computer world for decades.
I credit Woz for the IBM PC being what it was. Without the Apple 2, which got an amazing number of basics right, IBM may well have gone off and done just what you say Heater.
Wow! Yeah, what are you going to do with that thing?
My 8085 is in the Model 100 you convinced me not to gut. I had some travel, and why not? I got an image with all the goodies loaded. If I crash it, reload and go, everything running in RAM. Even has RAM filesystem. Crazy good, just tiny.
No idea what I might do with it. One day I might get around to powering it up and watch the two 7 segment displays on the front edge show its self-test and operating status.
That board has sentimental value to me. My adventures in Scandinavia started in 1996 when I took a contract involving that system. The task was to read all the 8086 assembly sources of the software on those boards, figure out what it does and recreate the functionality in C. The idea was to create a cross-platform version that they could then build for their new Motorola 68020 based traffic controllers running some RTOS. This was interesting because there was no documentation and very few comments in that code, the comments that were there were in Swedish! Those controllers were networked together and the communications protocol it used was home grown, undocumented and weird.
A six month contract assignment ended up taking nearly two years.
That ended up being the longest lived code I ever created. Some years later I was back at that company porting it to their new Power PC based hardware and some other RTOS. Then again when they moved to ARM. They thought I was nuts when I suggested throwing out the proprietary RTOS they were using and using Linux instead. I'm guessing we were one of the first adopters of Linux for such embedded systems.
There are still thousands of traffic controllers in Scandinavia running that code, which has it's origins in the assembler started in 1980 or so.
[quote="Heater.;1446077"
Has anyone ever made an EPROM simulator using a Propeller?
[/quote]
Not exactly an eprom simulator but I did use a propeller to write data to a 32K battery backed static ram that was also plugged into an eprom socket so the ram simulated the eprom it replaced. Worked really well for troubleshooting and writing software for the Z80 boards in some of the instruments I worked on back then.
That is not a bad idea. I have static RAM chips that could serve as fake EPROMS.
Conversely that board has lots if IO registers and uses PALs, presumably as address decoders and such. I was wondering about removing the V20 processor and driving it's socket with a Propeller so that I could fuzz the addresses and work out how the address map is laid out.
Man oh man, how many of us hated on x86! I am tinkering with 8085 right now too.
You are going to love my latest electronics archaeology acquisition then:
That is a Scandinavian traffic light controller CPU card from the early 1980's. Made by Ericsson.
It has an NEC V20 processor on it. The V20 was go faster clone of the Intel 8086 with a really weirdo feature, it has a mode where it runs the 8080 instruction set. You can switch between 8086 and 8080 on the fly.
@kwinn
...lets not forget that Intel and Microsoft also did their parts as well.
Indeed they did. However both Intel an MS were fly by night start ups at the time that nobody had ever heard of. At least compared to IBM which had dominate the computing landscape for decades.
There was a lot of face palming going on among the engineers around me the day the first IBM PC arrived in the company and they opened it up for a look see. I was in the signal processing group of the old Marconi Radar Company at the time. Those guys had been designing 16 bit processors for a long time so I took their opinions seriously.
I guess it could have been worse. Instead of hurriedly slapping together the 8086 PC, IBM could have come up with their own architecture and gained a lock on the personal computer world for decades.
Oh my @Heater I am jealous. Please keep us updated.
That is not a bad idea. I have static RAM chips that could serve as fake EPROMS.
Conversely that board has lots if IO registers and uses PALs, presumably as address decoders and such. I was wondering about removing the V20 processor and driving it's socket with a Propeller so that I could fuzz the addresses and work out how the address map is laid out.
That should work, although you might need buffers for 5V drive.
Yeah, I was wondering about that pesky level translation thing.
Any suggestions anyone?
Problem with using the Prop to drive the V20 bus is that you will not only have to write to the address bus but also read/write the data bus, and read/write the control signals.
If you are familiar with or willing to learn x86 instructions it might be simpler to build the ram based eprom emulator and use it to program the V20 to fuzz out the address map. You also end up with a pretty versatile tool.
Yep. Having the data and addresses multiplexed on to the same bus is a pain.
I have spent a lot of time with 8086 assembler, back in the day, see posts above. And now I recall spending almost a year tweaking the BIOS for a PC clone made my Nokia in 1982 or so. It was rebadged and sold in England by Northern Telecom. It was an amazing machine, much smaller than an XT and came with a high res. monochrome monitor that was better than the Mac. Again few comments in the assembler source and whatever was there was in Swedish of Finnish. Grrr...
Yeah, I was wondering about that pesky level translation thing.
Any suggestions anyone?
Hi Heater
In principle, you could start with a bunch of SN74LVC4245A-EP octal bus transceivers.
They can be used just like the elder and well-known LS245. Mouser has them at US$ 1.75 apiece, in tens quantities.
But, watch out, the direction and output enable control lines must be pulled high to +5V, so you need at least one more of them, layed out at the board, just to control the other ones, independently.
The board image you've posted above isn't well defined, so I'm not able to read the chip markings.
Could you confirm if the cpu at the socket is a V20 or a V20H?
The difference, at least from your intended "hacking" standpoint, is mainly due to the fact that the "original" V20 was not a fully static design, thus its clock must be kept running at a frequency >= 2MHz, in order to preserve its internal state/registers contents.
Not only the data bus is partly multiplexed with the address bus; the processor status lines (PS0,..., PS3) and the topmost nibble of the address bus (A16,..., A19) does also suffer from the same multiple personality disorder.
There are other control signals that have dual and even triple meaning; their definition depending on the small/large model selected by the state of the S/~LG pin (pin 33 in the Dip-40 package) and perhaps other concerns to take in account.
Appart from plain ttl and cmos gate-based designs, I've spent about twenty years (1987 - 2006) reverse-engineering of fuse-link prom, pal and gal-based ones. And sure, I've also created a huge bunch of my own ones, that needed to be well debuged prior to being released to my customers.
One thing I've learned so far; the more resources I've put into a "sniffer" hardware, i.e., the closer it is to a complete in-circuit emullator, the easier to deal with it, and the best results (with less coding efforts) I've got from them.
Ultimately I'm going to need a way to program those EPROMS. So I might just make a prom programmer from a Propeller. It also has two ZIF sockets for EEPROMS, so those need dealing with as well.
Ultimately I'm going to need a way to program those EPROMS. So I might just make a prom programmer from a Propeller. It also has two ZIF sockets for EEPROMS, so those need dealing with as well.
Old EPROMs could prove a problem..
For a while there, companies like Winbond has W27E512, which were MTP Eproms - ie pinouts the same as old EPROMS, but able to be electrically erased.
Those seem to have faded, (Quest show 47 plcc32 in stock) with more modern Flash parts like SST39SF010A-70-4C-PHE (Microchip Technology DIP32) being possible alternatives, but those could need an adapter ?
This board has good old Texas Instruments 27C512 with the UV erasing Window. I have a whole pile of of them.
Building a programmer for them sounds like a nice job for a Propeller. Needs similar voltage level translation as using the prop as a driver of the V20 socket or making a RAM based PROM emulator. Given that I want it to run from original EPROMS in the end I'm thinking I might as well go straight to the EPROM programmer.
P.S. Please, use the best voltage isolation between them and the propeller, during VPP(12V) and VID(12V, A9 Silicon I.D. Voltage) active. No fried props, please!
Comments
At a bit of a stretch I might claim the ARM was a 6502 variant. ACORN was using 6502 but wanted to go 32 bits whilst keeping that kind of simplicity, so they designed the ARM.
Modern ARMs are pretty CISCy mind.
Some targets are harder than others. But, if you drill down and stick with one long enough to get a couple respectable programs done, you will have accomplished a lot of the hard work.
And, when you pick your next target, know you will get a lot more done.
As much as I love PASM, it too is very beautiful, I do not feel it is important as a first target. Don't get me wrong here. It is just fine. Someone learning ASM is a good thing, no matter the CPU. But, one could get spoiled, that's all.
Honestly, that first target should be a CPU that you really want and need to accomplish something on.
That drive really helps. Each little thing done is meaningful and motivating. When you build on those early bits, maybe recoding them a little wiser, it is pretty great to see whatever it is happening at speed, or in some cases, just happening at all! (Often ASM is what makes the impossible, possible.)
Loved it even more when I subsequently had to work with the Intel 8085 then 8086. A painful step backwards.
We had done some assembler in Technical College but it was via a simulator running on some far away, telephone connected, main frame. I enjoyed that more that the BASIC we used for most of that CS course.
But I prefer the Prop P1. Even tho it's 32-bit, I think it's the easiest to learn by far! Regular instruction set, no accumulators, no interrupts, etc.
Now where is that Propeller assembly language programming tutorial AIman is asking for?
IIRC one of the main reasons the 6809 was such a pleasure to program in assembler was that it had a very orthogonal instruction set.
A trend we all thought would continue with the 68000.
Sadly the IBM PC with it's abomination of the Intel 8086 architecture blew that away.
Interestingly the year before the IBM PC was launched I was working with a very smart young CS graduate from Cambridge. We were building that 6809 processor board that I cut my assembly language programming teeth on.
One day he was expounding on the history of computing and made the claim that IBM has always held back progress in computing by at least ten years. I shrugged it off as I had no idea about such things.
Sure enough, the following year IBM gave us the PC and PC-DOS. That meant there was a 10 year delay between the 32 bit Intel 386 processor coming out (1985) and a 32 bit operating system for the masses (1998).
That young guy was so right!
Man oh man, how many of us hated on x86! I am tinkering with 8085 right now too.
He certainly was right, but lets not forget that Intel and Microsoft also did their parts as well.
That is a Scandinavian traffic light controller CPU card from the early 1980's. Made by Ericsson.
It has an NEC V20 processor on it. The V20 was go faster clone of the Intel 8086 with a really weirdo feature, it has a mode where it runs the 8080 instruction set. You can switch between 8086 and 8080 on the fly.
@kwinn Indeed they did. However both Intel an MS were fly by night start ups at the time that nobody had ever heard of. At least compared to IBM which had dominate the computing landscape for decades.
There was a lot of face palming going on among the engineers around me the day the first IBM PC arrived in the company and they opened it up for a look see. I was in the signal processing group of the old Marconi Radar Company at the time. Those guys had been designing 16 bit processors for a long time so I took their opinions seriously.
I guess it could have been worse. Instead of hurriedly slapping together the 8086 PC, IBM could have come up with their own architecture and gained a lock on the personal computer world for decades.
Wow! Yeah, what are you going to do with that thing?
My 8085 is in the Model 100 you convinced me not to gut. I had some travel, and why not? I got an image with all the goodies loaded. If I crash it, reload and go, everything running in RAM. Even has RAM filesystem. Crazy good, just tiny.
Was a very smart implementation by Gates.
That board has sentimental value to me. My adventures in Scandinavia started in 1996 when I took a contract involving that system. The task was to read all the 8086 assembly sources of the software on those boards, figure out what it does and recreate the functionality in C. The idea was to create a cross-platform version that they could then build for their new Motorola 68020 based traffic controllers running some RTOS. This was interesting because there was no documentation and very few comments in that code, the comments that were there were in Swedish! Those controllers were networked together and the communications protocol it used was home grown, undocumented and weird.
A six month contract assignment ended up taking nearly two years.
That ended up being the longest lived code I ever created. Some years later I was back at that company porting it to their new Power PC based hardware and some other RTOS. Then again when they moved to ARM. They thought I was nuts when I suggested throwing out the proprietary RTOS they were using and using Linux instead. I'm guessing we were one of the first adopters of Linux for such embedded systems.
There are still thousands of traffic controllers in Scandinavia running that code, which has it's origins in the assembler started in 1980 or so.
https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/
So now I can write some C for my old 8086 card. Or assembler:
.arch i8086,jumps .code16 .att_syntax prefix .section .rodata .LC0: .string "Hello world!" .text .global main .type main, @function main: pushw %bp movw %sp, %bp movw $.LC0, %ax pushw %ax call puts addw $2, %sp movw $0, %ax movw %ax, %ax movw %ax, %ax movw %bp, %sp popw %bp retHas anyone ever made an EPROM simulator using a Propeller?Has anyone ever made an EPROM simulator using a Propeller?
[/quote]
Not exactly an eprom simulator but I did use a propeller to write data to a 32K battery backed static ram that was also plugged into an eprom socket so the ram simulated the eprom it replaced. Worked really well for troubleshooting and writing software for the Z80 boards in some of the instruments I worked on back then.
Conversely that board has lots if IO registers and uses PALs, presumably as address decoders and such. I was wondering about removing the V20 processor and driving it's socket with a Propeller so that I could fuzz the addresses and work out how the address map is laid out.
Oh my @Heater I am jealous. Please keep us updated.
That should work, although you might need buffers for 5V drive.
Any suggestions anyone?
Problem with using the Prop to drive the V20 bus is that you will not only have to write to the address bus but also read/write the data bus, and read/write the control signals.
If you are familiar with or willing to learn x86 instructions it might be simpler to build the ram based eprom emulator and use it to program the V20 to fuzz out the address map. You also end up with a pretty versatile tool.
I have spent a lot of time with 8086 assembler, back in the day, see posts above. And now I recall spending almost a year tweaking the BIOS for a PC clone made my Nokia in 1982 or so. It was rebadged and sold in England by Northern Telecom. It was an amazing machine, much smaller than an XT and came with a high res. monochrome monitor that was better than the Mac. Again few comments in the assembler source and whatever was there was in Swedish of Finnish. Grrr...
Hi Heater
In principle, you could start with a bunch of SN74LVC4245A-EP octal bus transceivers.
They can be used just like the elder and well-known LS245. Mouser has them at US$ 1.75 apiece, in tens quantities.
But, watch out, the direction and output enable control lines must be pulled high to +5V, so you need at least one more of them, layed out at the board, just to control the other ones, independently.
ti.com/product/SN74LVC4245A-EP
Henrique
The board image you've posted above isn't well defined, so I'm not able to read the chip markings.
Could you confirm if the cpu at the socket is a V20 or a V20H?
The difference, at least from your intended "hacking" standpoint, is mainly due to the fact that the "original" V20 was not a fully static design, thus its clock must be kept running at a frequency >= 2MHz, in order to preserve its internal state/registers contents.
Not only the data bus is partly multiplexed with the address bus; the processor status lines (PS0,..., PS3) and the topmost nibble of the address bus (A16,..., A19) does also suffer from the same multiple personality disorder.
There are other control signals that have dual and even triple meaning; their definition depending on the small/large model selected by the state of the S/~LG pin (pin 33 in the Dip-40 package) and perhaps other concerns to take in account.
Appart from plain ttl and cmos gate-based designs, I've spent about twenty years (1987 - 2006) reverse-engineering of fuse-link prom, pal and gal-based ones. And sure, I've also created a huge bunch of my own ones, that needed to be well debuged prior to being released to my customers.
One thing I've learned so far; the more resources I've put into a "sniffer" hardware, i.e., the closer it is to a complete in-circuit emullator, the easier to deal with it, and the best results (with less coding efforts) I've got from them.
Henrique
Ultimately I'm going to need a way to program those EPROMS. So I might just make a prom programmer from a Propeller. It also has two ZIF sockets for EEPROMS, so those need dealing with as well.
For a while there, companies like Winbond has W27E512, which were MTP Eproms - ie pinouts the same as old EPROMS, but able to be electrically erased.
Those seem to have faded, (Quest show 47 plcc32 in stock) with more modern Flash parts like SST39SF010A-70-4C-PHE (Microchip Technology DIP32) being possible alternatives, but those could need an adapter ?
Building a programmer for them sounds like a nice job for a Propeller. Needs similar voltage level translation as using the prop as a driver of the V20 socket or making a RAM based PROM emulator. Given that I want it to run from original EPROMS in the end I'm thinking I might as well go straight to the EPROM programmer.
What about the eraser? I'm thinking we can do that with a high power UV LED now a days. If the wavelength is suitable. The EPROMS call for 254nm but the UV LEDS I'm finding put out between 365nm and 420nm. Or there is the old school filament UV lamp "E17 3W 254NM Sterilization Light UV" https://www.ebay.com/itm/E17-3W-254NM-Sterilization-Light-UV-Disinfection-Lamp-for-Refrigerator-Microwav/283127404048?hash=item41ebb55610:g:U9MAAOSwxyJbhPTa But that starts getting big and expensive.
There is also space for two EEPROMS in ZIF sockets for customer code. They are XLS2864
ebay 10 x W27C512-45Z at US$5.50/lot
https://ebay.com/itm/10pcs-W27C512-45Z-W27C512-27C512-Winbond-EEPROMs-/280775969072?_ul=BR
Bonnus: WINDOWSless
Addit: https://media.digikey.com/pdf/Data%20Sheets/Winbond%20PDFs/W27C512.pdf
The quartz window is a feature I like. You can see the chip working!
Except you can't when the chip is installed and covered with a UV proof sticker, so it makes no odds really.
And also better than Tiger Woods eyes too! :nerd: