RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

Home » RBC Forums » General Discussion » Intel 8051 MCU dev board, revisited
Intel 8051 MCU dev board, revisited [message #10428] Tue, 19 September 2023 04:29 Go to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
I've been working on a CPLD version of the duodyne Z80 processor board which lead to the development of an EPM7128SLC84 dev board. That, in turn, ignited my interest in dev boards which I recall from college but really haven't done much with in a long time. I did some searching around for a retrocomputer-like dev board and came across this:

https://www.pjrc.com/tech/8051/board5/index.html

Yes, Intel 8051 is and old MCU but ubiquitous and are still commonly in use today in many forms. So useful and interesting. The website above has public domain software for an 8051 monitor (PAULMON) plus plans for 8051 dev boards spanning multiple generations. Unfortunately, it appears to have gone dormant and hasn't been updated in over ten years. The latest board design is from 2005 which is from 18 years ago.

I've done some additional searching and there are many 8051 type designs available on the internet. Most of which have a great deal in common such as an 8051 MCU, address latch, a ROM chip, sometimes RAM, and peripherals. Typically, a serial port of two to communicate with the dev board.

I don't think we could just use the PJRC board "as-is" since they are out of stock and have been so for quite a while. However, we could take some inspiration from their webpage and design an updated version of the 8051 MCU dev board. One that is loosely inspired by the PJRC board but different in many ways. I can think of many useful applications. Foremost would be "smart" peripherals for duodyne but I am sure others would have interesting things to do with it. Especially when paired with a CPLD, a modernized 8051 MCU is quite a powerful concept.

Yes, there are newer versions like AT89S52 which warrant consideration. Available in DIP-40 it has a lot of the memory and peripherals built-in. However, I am leaning toward the SAB80535 in PLCC-68 because it adds and additional three 8-bit GPIO ports and seems to keep good compatibility with the original 8051 design. Plus available in PLCC through-hole for easy construction. It would easily fit on a 160x100mm protoboard and be relatively inexpensive to build.

Would anyone else be interested in an 8051 MCU dev board renaissance project? Maybe there are some already and I am just not aware of them.

Thanks, Andrew Lynch

[Updated on: Tue, 19 September 2023 04:31]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10432 is a reply to message #10428] Wed, 20 September 2023 03:35 Go to previous messageGo to next message
edzard is currently offline  edzard
Messages: 64
Registered: August 2019
Member
Hello Andrew,

That's a blast from the past!

I would be (very) interested in a SAB80535/80537 design.

Here over in Europe the Siemens MCU were quite popular and used by some Elektor/Elektuur designs.
If added some older articles (1997) from https://www.elektormagazine.com



Best regards,

Edzard
  • Attachment: e976044.pdf
    (Size: 2.04MB, Downloaded 201 times)
  • Attachment: e002040.pdf
    (Size: 246.76KB, Downloaded 201 times)

[Updated on: Wed, 20 September 2023 03:37]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10433 is a reply to message #10432] Wed, 20 September 2023 08:35 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Nice! Thanks Edzard!

The SAB80C535 is a scaled down (PLCC-68), smaller version of SAB80C537 (PLCC-84) with fewer on-board peripherals and ports but still more than a basic 80C51 or clone. I thought it was a good compromise and upgrade to the PJRC design. There are some differences between the SAB80C535 and the 80C51 such as the reset line on the 80C51 is active high and the SAB80C535 it is active low. Reading through the datasheet I've noticed a few other differences with ~EA and ~PE but nothing too severe. The design adjustments are fairly minor.

I am using 512KB SRAM and 512KB Flash ROM to update the design and added a simple bank switching latch to control the upper address lines. The basic board design has two serial ports (TTL serial to USB) and two 82C55 PPIs for 48 GPIO pins (8 are encumbered with LEDs). The SAB80C535 adds 3 unencumbered 8-bit GPIO ports for 24 GPIO pins. That's important because although it looks like the 80C51 has a lot of GPIO pins, many of the pins on ports 0-3 are encumbered with "secondary" functions that turn out to be necessary.

There is a 14-pin LCD port and an expansion bus (sort of) with four free chip selects. The original design has a few regular 74xx style logic chips which I've consolidated into a GAL16V8 and a GAL22V10.

My goal with this board in the short term is to get the basic design working and bugs fixed. Longer term, I would like to add an EPM7128S CPLD connected to all the GPIO pins. I think the combination of MCU with CPLD is a powerful combination and could be a virtual prototyping board for all sorts of projects. My current design is only the MCU portion, and it fits on a 160x100mm Euroboard with a small 3.5"x1.5" prototyping area.

Thanks, Andrew Lynch

Re: Intel 8051 MCU dev board, revisited [message #10434 is a reply to message #10433] Wed, 20 September 2023 08:38 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
PS, I thought the 80C51 would be an appropriate project for retrobrew computers because it is roughly the same vintage as 6502, 8085, and Z80. Plus external memories and peripherals is a plus in my opinion since it is more easily customized.
Re: Intel 8051 MCU dev board, revisited [message #10435 is a reply to message #10434] Sun, 24 September 2023 10:02 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
Doing more work on the SAB80C535 dev board project. Mostly little fixes and cleanup of the PCB. Putting the pullup resistor networks in sockets so they don't always have to encumber the GPIO port, etc.

One important note in how this board differs from the PJRC 80C51 dev board. The PJRC board uses onboard ROM (4K or 8K) to store their boot code and monitor which is copied to Flash upon boot.

Since the SAB80C535 has no onboard ROM (SAB80C515 has 8KB of factory mask ROM) the Flash has to start at 0x0000 for the boot code.

The PJRC board has its RAM at 0x0000-0x7FFF, Flash at 0x8000-0F7FF, and memory mapped IO at 0xF800-0xFFFF. The SAB80C535 will have the Flash and RAM reversed so it has boot code in Flash when it starts executing after reset at 0x0000.

I would still like to use the public domain PAULMON and I think I can modify it work with the new configuration.
Offer To Help 8051 [message #10436 is a reply to message #10434] Sun, 24 September 2023 10:06 Go to previous messageGo to next message
jayindallas is currently offline  jayindallas
Messages: 110
Registered: June 2021
Senior Member
I did an 8051-based design in '90s and I'll be glad to help with what I learned about that processor and coding it.

Its a hidden jewel, but one might not recognize that right away; I sure didn't when I first used it in '80s. It seemed obtuse for simple applications; maybe it is? But it excels at quickly handling multiple levels of critical interrupts. I was very impressed with what the 8051 could accomplish as a realtime controller, after taking the time to study it very deeply.

[Updated on: Thu, 26 October 2023 12:30]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10437 is a reply to message #10436] Sun, 24 September 2023 19:00 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
Thanks, that's good to know. 8051 is a very common MCU and it lives on in all sorts of things. I can see why people like it so much. I have been thinking about a "smart" peripheral for a while and the 8051 seems like a good controller for that application.

My design is inspired by the PJRC 8051 dev board but I am making some significant changes by adopting the SAB80535 as the MCU. The design retains the dual serial port though which as you said multiplexes the one serial port with T0 signal for a console port and application port. It's a neat idea and I was able to consolidate the logic into GAL that reduced part count.

Another change is the SAB80535 uses an active low reset signal while the older 8051 type MCUs tend to use active high. I am trying to keep this project simple and small so not too much additional stuff. The PJRC design has a pretty good balance and is able to keep it within a Euroboard with some room for a prototype area.

I've added a simple bank switching circuit to use larger SRAM and Flash chips. It is easy to get really complicated on the bank switching so we'll see if the 8-bit latch approach is sufficient.

The PJRC design also uses Flash programming in-circuit as part of its boot process. I am thinking since the Flash is a different chip that I'll pass on the in-circuit reprogramming for a while until after there are some basic "proof of life" tests accomplished. I'd really like to port PAULMON but I think there are other 8051 style monitors available too.

Thanks, Andrew Lynch

PS, I'll send you a PCB if you are interested once I get some manufactured. I am doing this project as a pair with the EPM7128S dev board and would eventually like to combine them but that will take some time.

[Updated on: Sun, 24 September 2023 19:03]

Report message to a moderator

Offer To Study The Monitor Program [message #10438 is a reply to message #10437] Sun, 24 September 2023 23:38 Go to previous messageGo to next message
jayindallas is currently offline  jayindallas
Messages: 110
Registered: June 2021
Senior Member
Regarding PAULMON, If you post some links on that, I'll start studying it, to figure out what modifications would be required to adapt it to your new design.
I'll study your 8051 chip selection and schematics when they're available to advise how PAULMON can be modified for it.
Update: all those links have been provided. Thanks.

[Updated on: Thu, 26 October 2023 12:32]

Report message to a moderator

PAULMON on SDCC's Simulator? [message #10439 is a reply to message #10438] Sun, 24 September 2023 23:50 Go to previous messageGo to next message
jayindallas is currently offline  jayindallas
Messages: 110
Registered: June 2021
Senior Member
UPDATE: 10/29/2023
I like the features added to PAULMON over time and the author's clever ways to balance each addition to codespace with a counter balancing subtraction of codespace. Its the natural way code is updated over time... you get a new idea, you make it happen in code and you make some quick compromises to make it fit again. Now and then, when you have some time, you do another version update; same code function, but with the luxury of time, you can re-write it to integrate the incremental feature additions with the perspective of the whole body of code. That's all I'm doing, PAULMON is the author's work. I've got some time and so I'm just doing a tweak to help out.

This week I'm going to change the format of the assembly code so it can use the SDCC assembler/c-compiler/IDE/Simulator that Andrew Lynch suggested using.
SDCC's assembler format uses common syntax. I've done most of it, the last section is operand boolean manipulation (in parentheses); I want to take the time do do that carefully to minimize chaos.

My planned changers are:
1) Take advantage of Register addressing using all FOUR banks.
2) Write a line/string format interpreter with auto-incrementing address referencing.
3) Write a line/string parser.
4) Maybe, maybe, maybe, write a background-tasker, to automatically control streams.

I'm working (2) right now. I've starting off with simple strings, and when that works, I'll add more format features. PAULMON has a nice dictionary table to reduce codespace and the last phase of (2) will be making it accept dictionary word references in strings, too.

I'd like to take (2) far enough that the DUMP memory routine would only require:
(1) Print a prefix string.
(2) Format a single typical HEX DUMP line with address, 16 bytes in hex, and an ascii block, inside a loop for how many lines needed.
(3) Print a suffix string.

[Updated on: Sun, 29 October 2023 10:09]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10440 is a reply to message #10439] Mon, 25 September 2023 04:06 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
This is the PJRC 8051 dev board that got me interested in pursuing this project

https://www.pjrc.com/tech/8051/board5/index.html

Unfortunately, it has not been available for 15-20 years or so but still it is a cool retro project. My design is not so much a clone as an "inspired by" the PJRC board mostly because I can't procure theirs anymore, so I have to build a new one if I want one. However, a lot of the parts they used are kind of out of date, so I am trying to modernize the design somewhat.

Here is a link to PAULMON which, as you said, is a public domain 8051 monitor program. It is small, only about 4K in length and fits in the onboard ROM of an 8051. The downside is the modernized MCU I selected (SAB80535) is ROMless so it requires a different memory map than the PJRC board (RAM and Flash reversed in memory). The PAULMON seems to be well written and should be mostly changing constants to get it to start to some minimal level of functionality. However, other things like the Flash ROM in-circuit programming will probably need major rewrites. Fortunately, I don't think we need in-circuit Flash programming right away although eventually it will be necessary.

https://www.pjrc.com/tech/8051/paulmon2.html

Here is a link to the SAB80535 dev board I've been working on and a picture of the 3D rendering to help visualize the design. As usual, all the KiCAD design files are available. My goal is not to make a clone of the PJRC board although that would have been easier. I would like to have more GPIO ports and use the Flash ROM for all the programming instead of reprogramming the 87C52 itself. My programmer TL866II supports 87C52 programming (with an adapter). I think it's hard enough keeping track of one ROM version much less two.

https://github.com/lynchaj/duodyne/tree/main/SAB80535-Dev-Bo ard

https://github.com/lynchaj/duodyne/blob/main/SAB80535-Dev-Bo ard/SAB80535-Dev-Board.jpg

Of course, I'll send you a PCB and you can put whatever you like on it. PAULMON is just a suggestion but if you have your own 8051 monitor that works then by all means go ahead and use it. There are probably other suitable 8051 monitor programs to use as well. I just picked PAULMON because it looks well designed and portable.

Thanks!

PS, if anyone else would like one of these PCBs to experiment on please let me know. Assuming you live in the US of course. International shipping has become absurdly, ridiculously expensive lately. Wow, I miss the days of reasonable shipping rates...

[Updated on: Mon, 25 September 2023 04:07]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10441 is a reply to message #10440] Mon, 25 September 2023 09:18 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
In the PAULMON2 page, it seems to imply it has been ported to 8051 type boards other than the PJRC. About halfway down the page, there is a list of preassembled binaries for different memory configurations including one for RAM at 0x8000-0xFFFF which is similar to the SAB80535 dev board design I am working on presently.

I doubt the preassembled binary would work "as-is" but it might do something visible before crashing. They also suggest EPROM at 0x0000 to 0x1FFF so that's consistent as well. In my design there is ROM from 0x0000 to 0x7FFF, plenty of room for PAULMON2 and whatever extras come along too.

Really looking forward to ordering these boards. It seems these will be a lot of fun to get up and running. Also useful down the road a bit.

[Updated on: Mon, 25 September 2023 09:19]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10442 is a reply to message #10438] Mon, 25 September 2023 09:24 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
jayindallas wrote on Mon, 25 September 2023 02:38

My proof of concept (POC) boards running PAULMON-8051 will not be as fancy as your newer 8051 selection-and-design but if it works on the POC, it can be made to work on your new design with any other features you specify as your design boards become ready. My POCs used a circa '98 Philips 8051, but I switched production to Temic 8051s that were better. Temic was acquired by another company around that time.

Do you have the design information for your POC design? Schematics, EDA files, etc.? If it's just some parts obsolescence issues, they could probably be designed out and bring your POC back to life as a retrocomputer board. Then others could enjoy it too. Do you have any photos? Please post if available

Thanks!
PAULMON Updates [message #10446 is a reply to message #10442] Tue, 26 September 2023 13:02 Go to previous messageGo to next message
jayindallas is currently offline  jayindallas
Messages: 110
Registered: June 2021
Senior Member
PAULMON :: Change of Plan - SIMPLIFY!
Keep it simple; I'm just writing PAULMON plainly, removing the compressed code constructs that maintain its 4K size goal. As 4K is not a limit in AJ's design, I'm trading code compression, for code that is easier to read and modify. I will try to compress the code too, but in a more-inline method, using datastructures, register banks and a few tricks I used 25 years ago.

Two options will be available:
(1) PAULMON 4K: as it exists in downloads.
(2) PAULMON Simplified: a version of PAULMON, written so its easier to read and modify.

[Updated on: Thu, 26 October 2023 12:49]

Report message to a moderator

Re: PAULMON Update & Q&A Regarding the '90s Project (8051) [message #10449 is a reply to message #10446] Tue, 03 October 2023 03:56 Go to previous messageGo to next message
Yves-D. is currently offline  Yves-D.
Messages: 21
Registered: January 2020
Junior Member
Hi,

I'm happy to see that the old 8051 gets some recognition as retro-processor.
I was thinking along the same lines as Andrew in doing a retro project with the 8051 family.

@Andrew:
You're basically set at the SAB80C535 architecture, but there have been plenty of interesting additions to the 8051 architecture in the 2nd half of it's lifecycle (i'm just giving food for thought here)

- Dallas DS80C320 / DS80C400 running up to 75Mhz

- Philips/NXP P89C51RD2 - has onboard EPROM and a serial bootloader ex. factory (the programming cycle is documented in the manual)
This one can mimic the ROM-part of the 87C51 (e.g. for PaulMon or MCS-Basic)
see here https://www.dos4ever.com/isp/isp.html
The SST89V54RD2 relates closely, is more recent with same additional twists. But availability is spotty, doesn't really qualify as retro.

- NXP 80C32X2 / Atmel TS 80C32X2 - can run up to 33Mhz and has a faster 6 clock-machine-cycle (opposed to the 12 clock-machine-cycle)
dirt cheap as PLCC, vast amounts of these seem to have been produced.

- I've revisited the Intel MCS Basic lately and have been amazed by the I/O feature-set they put in at the time.
There have been several improvements/fixes by enthusiasts, see here https://www.dos4ever.com/8031board/8031board.html
MCS Basic V1.3 could even address an 28C64 EEPROM for permanent program storage and automatic program start at power on.
The 80C535 got an adaptation too.

- An interesting (free) book on the 8051 (MCS-Basic and circuit ideas) is to be found here:
http://janaxelson.com/files/microcontroller_idea_book.pdf

Kind regards,
Yves
Re: PAULMON Update & Q&A Regarding the '90s Project (8051) [message #10450 is a reply to message #10449] Tue, 03 October 2023 10:00 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi Yves
Thanks for link to interesting MCU book. The circuit for 8052 sample board is essentially the same one for what I am doing with SAB80535 dev board. It's a simple design with 32KB ROM at 0x0000-0x7FFF and 32KB RAM at 0x8000-0xFFFF plus a few basic peripherals like two 8255 PPI, LCD interface, pair of serial ports, etc. Not very fancy but I think useful.

Thanks, Andrew Lynch

A Tutorial on 8051 Register Banks. Update: 10/11 [message #10451 is a reply to message #10446] Thu, 05 October 2023 09:40 Go to previous messageGo to next message
jayindallas is currently offline  jayindallas
Messages: 110
Registered: June 2021
Senior Member
TITLE: A Tutorial on 8051 Register Banks. Update: 10/11
MESSAGE:
Update: 10/24/2023
Tutorial on the 8051 Register Banks
Part 01: . . . Introduction to the Register Banks and Register Syntax, 'Rn' and '@Ri':

The Register Banks (RB) are a set of four banks of eight consecutive, internal RAM bytes. When a bank is selected, its eight RAM bytes are addressed by the operand syntax 'Rn' for registers {R0,R1,R2,R3,R4,R5,R6,R7} or 'R0:R7'. An instruction using R0:R7 can thus encode each register address within 3-bits of the opcode, and within the selected RB addresses. This is referred to as 'register addressing'. To select any Register Bank, write to the Special Function Register (SFR) PSW, bit 4 and bit 3 or "xxxBBxxx" binary where BB represents the binary number of the selected bank.

PSW to select the Active Register Bank and R0:R7 mapped to that Bank's internal RAM addresses:
											      R0  R1  R2  R3  R4  R5  R6  R7
 mov	psw,xxx00xxxb		;select RB#0	with R0:R7	mapped to -> 00:07h	RB#0 [00][01][02][03][04][05][06][07]
 mov	psw,xxx01xxxb		;select RB#1	with R0:R7	mapped to -> 08:0Fh	RB#1 [08][09][0A][0B][0C][0D][0E][0F]
 mov	psw,xxx10xxxb		;select RB#2	with R0:R7	mapped to -> 10:17h	RB#2 [10][11][12][13][14][15][16][17]
 mov	psw,xxx11xxxb		;select RB#3	with R0:R7	mapped to -> 18:1Fh	RB#3 [18][19][1A][1B][1C][1D][1E][1F]

This 3-bit encoding allows most of these instructions to be one byte and execute in one cycle, or '1b1c'. Its an efficient and advantageous construct for coding faster runtime and smaller codespace.
BAD:	push	Acc		;2b2c	; save Acc value on the stack (direct addressing access: SFR 'Acc')
	...
	pop	Acc		;2b2c	; restore Acc value off the stack (direct addressing access: SFR 'Acc')
Bad Total:			;4b4c	; TOTAL
GOOD:	mov	R2,a		;1b1c	; save Reg A value to R2
	...
	mov	a,R2		;1b1c	; restore Reg A value from R2
GOOD Total:			;2b2c	; TOTAL

The additional operand syntax '@Ri' refers to {@R0,@R1} a subset of 'Rn', that additionally can be used for 'indirect addressing' to any internal RAM address within the address bounds of 00:FFh. Indirect addressing uses the contents of the specified register, within the currently selected Register Bank, as the address in internal RAM 00:FFh that is quickly accessed. Even though indirect addressing involves an additional step to get the RAM address from the @Ri register, it is one byte and execute in one cycle, or '1b1c'.

Note that Register Bank instructions that require more than one cycle or more than one byte, are longer due to another operands or another operation. In Part 02, you can see these instructions tabulated.

That's the BASICS of the construct. Part 02 will survey the applicable instructions, and Part 03 will discuss some guidelines on how register banks and register addressing can improve a coding situation.


Part 02: . . . A Survey of 8051 Instructions that Utilize the Register Bank Construct:

The code tables below list the four instruction groups that have Register Bank Constructs. For each table, the upper set of instructions use register addressing, 'Rn' and the lower set of instructions use indirected addressing, '@Ri'.

Try to use the 1 Byte, 1 Cycle instructions below, whenever possible, to run fast and to reduce codespace. Rn, as R0:R7, only addresses the internal RAM of the selected register bank. However, @R0 and @R1 can address any internal RAM from 00:FFh by indirect addressing. In contrast, generally only direct address instructions can address SFRs. The exceptions are instructions that use operands {A,AB,DPTR}.
 ________________________ARITHMETIC OPERATIONS___________________________________________________
| Mnemonic             | Description                                            | Bytes | Cycles |
|______________________|________________________________________________________|_______|________|
| REGISTER ADDRESSING: |                                                        |       |        |
| add  | A,Rn          | Add register to Accumulator                            |   1   |   1    |
| addc | A,Rn          | Add register to Accumulator with Carry                 |   1   |   1    |
| subb | A,Rn          | Subtract register from Accumulator with Borrow         |   1   |   1    |
| inc  | Rn            | Increment Register                                     |   1   |   1    |
| dec  | Rn            | Decrement Register                                     |   1   |   1    |
| INDIRECT ADDRESSING: |                                                        |       |        |
| add  | A,@Ri         | Add indirect RAM to Accumulator                        |   1   |   1    |
| addc | A,@Ri         | Add indirect RAM to Accumulator with Carry             |   1   |   1    |
| subb | A,@Ri         | Subtract indirect RAM from Accumulator with Borrow     |   1   |   1    |
| inc  | @Ri           | Increment indirect RAM                                 |   1   |   1    |
| dec  | @Ri           | Decrement indirect RAM                                 |   1   |   1    |
|______|_______________|________________________________________________________|_______|________|


Try to use the 1 Byte, 1 Cycle instructions below, whenever possible, to run fast and to reduce codespace. Rn, as R0:R7, only addresses the internal RAM of the selected register bank. However, @R0 and @R1 can address any internal RAM from 00:FFh by indirect addressing.
 ________________________LOGICAL OPERATIONS______________________________________________________
| Mnemonic             | Description                                            | Bytes | Cycles |
|______________________|________________________________________________________|_______|________|
| REGISTER ADDRESSING: |                                                        |       |        |
| anl  | A,Rn          | And register to Accumulator                            |   1   |   1    |
| orl  | A,Rn          | Or register to Accumulator                             |   1   |   1    |
| xrl  | A,Rn          | Exclusive-Or register to Accumulator                   |   1   |   1    |
| INDIRECT ADDRESSING: |                                                        |       |        |
| anl  | A,@Ri         | And indirect RAM to Accumulator                        |   1   |   1    |
| orl  | A,@Ri         | Or indirect RAM to Accumulator                         |   1   |   1    |
| xrl  | A,@Ri         | Exclusive-Or indirect RAM to Accumulator               |   1   |   1    |
|______|_______________|________________________________________________________|_______|________|


Some instructions to use often: The xch a,Rn and xch a,@Ri instructions should be constantly in your mind, for using in register addressing sections. Its very efficient as it can swap to bytes in a single opcode byte and cycle ('1b1c'). Using this cleverly, you can create a pseudo-@Ri by swapping 8-bit address value in Ri. Also note the inc Rn and dec Rn can be used to bump the indirect address quickly. Consider the djnz Rn,rel for looping though it a 2b2c instruction. Try to use these instructions below, whenever possible, to run fast and to reduce codespace in contrast to an instruction with a 'direct,direct' operand. There are times when a 'direct,direct' operand instruction is faster than initializing a Rn or @Ri instruction.
 ________________________DATA TRANSFER___________________________________________________________
| Mnemonic             | Description                                            | Bytes | Cycles |
|______________________|________________________________________________________|_______|________|
| REGISTER ADDRESSING: |                                                        |       |        |
| mov  | A,Rn          | Move Register to Accumulator                           |   1   |   1    |
| mov  | Rn,A          | Move Accumulator to Register                           |   1   |   1    |
| mov  | Rn,direct     | Move direct byte to Register                           |   2   |   1    |
| mov  | Rn,#data      | Move immediate data to Register                        |   2   |   1    |
| mov  | direct,Rn     | Move Register to direct byte                           |   2   |   2    |
| xch  | A,Rn          | Exchange Register with Accumulator                     |   1   |   1    |
| INDIRECT ADDRESSING: |                                                        |       |        |
| mov  | A,@Ri         | Move indirect RAM to Accumulator                       |   1   |   1    |
| mov  | direct,@Ri    | Move indirect RAM to direct byte                       |   2   |   2    |
| movx | A,@Ri         | Move external RAM (8-bit addr) to Accumulator          |   1   |   2    |
| movx | @Ri,A         | Move Accumulator to external RAM (8-bit addr)          |   1   |   2    |
| xch  | A,@Ri         | Exchange indirect RAM with Accumulator                 |   1   |   1    |
| xchd | A,@Ri         | Exchange low-order digit indirect RAM with Accumulator |   1   |   1    |
|______|_______________|________________________________________________________|_______|________|


 ________________________PROGRAM BRANCHING_______________________________________________________
| Mnemonic             | Description                                            | Bytes | Cycles |
|______________________|________________________________________________________|_______|________|
| REGISTER ADDRESSING: |                                                        |       |        |
| cjne | Rn,#data,rel  | Compare Immediate to Register and jump if not equal    |   3   |   2    |
| djnz | Rn,rel        | Decrement Register and jump if not zero                |   2   |   2    |
|      |               |                                                        |       |        |
| INDIRECT ADDRESSING: |                                                        |       |        |
| cjne | @Ri,#data,rel | Compare Immediate to indirect and jump if not equal    |   3   |   2    |
|______|_______________|________________________________________________________|_______|________|


Part 03: . . . Coding Situations Where Register Banks are Well Applied:

INTRODUCTION: . . . Part 03:

Part 03 inserts a quick review of the internal data memory access by direct and indirect addressing.
Thereafter are some illuminating scenarios using Register Banks to write faster and smaller code.

Scenario #1 A routine calls a subroutine. Each use a separate Register Bank.
Scenario #2 Foreground passes control to an interrupt service routine. Each use a separate Register Bank.


QUICK REVIEW: . . . 'Internal Data Memory':

Its important to know the difference between the overlay resources in the internal RAM address block, 80:FFh. Both the 'Upper 128" RAM block and the SFRs use some of the same addresses; but the key is knowing that its the addressing mode that distinguishes the target resource. Learning this now will avoid writing code to access SFRs, that will actually access the 'Upper 128' RAM addresses, or vise-versa. So this quick review is a necessary place to begin.

(1) The Lower 128 is the 00:7Fh block of RAM. It is accessible by direct and indirect (@Ri) 8-bit addressing.
(2) The Upper 128 is the 80:FFh block of RAM. It is accessible only by indirect (@Ri) 8-bit addressing.
(3) The Special Function Registers (SFRs) is an overlay in the 80:FFh block. It is accessible only by direct 8-bit addressing.


SCENARIO #1: . . . Call a Subroutine that Assigns Itself another Register Bank:

Generally, when calling a subroutine, parameters are passed and results are returned. An 8051 has a small environment, so care has to be taken to avoid overloading the stack or wasting time with SAVE/RESTORE procedures. If a subroutine serves only one call location, the programmer can plan the subroutine code to avoid resources that should be preserved and to use others that are available. It can get more complicated when the subroutine supports many call locations.

A good guideline would be to expect register A and any flags to be changed by the subroutine. However, I'll write the example subroutine below to save the calling routine's environment but will put the result in Reg A, and save a copy of the original Reg A in the subroutine's Register Bank (RB) R6. If the calling routine needs that original Reg A value, it can read the saved image by direct addressing: mov a,16h.

In the example below, the scenario is that the subroutine needs a lot of registers for calculations and the calling routine has a lot of registers it doesn't want the subroutine to disturb. Instead of pushing and popping values on the stack, the calling routine will be using RB#0 and the subroutine will use RB#2 for its calculations and anything it needs to save for the calling routine. It will return a result in Reg A, and the PSW flags and RB will be restored for the calling routine.

The priority task for the subroutine getting a Register Bank (RB) is:
(1) Save the psw flags and RB selection before changing the RB# or Reg A. Use direct address 17h=RB#2+R7.
(2) Save Reg A for the calling routine only it its necessary. Use direct address 16h=RB#2+R6
(3) Select the RB#2 for the subroutine.

In Line1 below, saves PSW by direct addressing into 17h=RB#2+R7.
In Line2 below, saves Reg A by direct addressing into 16h=RB#2+R6. If the calling routine doesn't need Reg A saved, delete Line2.
In Line3 below, the ISR selects RB#2.
		;-----------------------; RB#0 is active from the calling routine
		; RB#0 Ram Addresses	; NOTE: none of these registers are changed by the subroutine.
		; RB#0+R0->00h  [ ]	; 
		; RB#0+R1->01h  [ ]	;
		; RB#0+R2->02h  [ ]	;
		; RB#0+R3->03h  [ ]	;
		; RB#0+R4->04h  [ ]	;
		; RB#0+R5->05h  [ ]	;
		; RB#0+R6->06h  [ ]	;
		; RB#0+R7->07h  [ ]	;
		;-----------------------; for clarity, interrupt enable/disable code is removed
Subroutine+Register_Bank:		;
		;-----------------------; 
Line1:	mov	17h,psw		;3b2c	; save the calling routine's psw in direct address of 17h=RB#2+R7
Line2:	mov	16h,a		;3b2c	; save the calling routine's Reg A by direct addressing of 16h=RB#2+R6; Could delete this.
Line3:	mov	psw,#10h	;3b2c	; select RB#2, if the subroutine requires the calling routine's psw flags, use r7's image
		;-----------------------; the calling routine can restore Reg A (if it was saved) by direct addressing: mov a,16h
		; RB#2 Ram Addresses	; 
		; RB#2+R0->10h  [ ]	; RAM byte available to subroutine
		; RB#2+R1->11h  [ ]	; RAM byte available to subroutine
		; RB#2+R2->12h  [ ]	; RAM byte available to subroutine
		; RB#2+R3->13h  [ ]	; RAM byte available to subroutine
		; RB#2+R4->14h  [ ]	; RAM byte available to subroutine
		; RB#2+R5->15h  [ ]	; RAM byte available to subroutine
		; RB#2+R6->16h  [Reg A]	; copy of calling routine's Reg A, loaded by direct addressing 16h=RB#2+R6
		; RB#2+R7->17h  [PSW]	; copy of calling routine's PSW flags and register bank loaded by direct addressing 17h=RB#2+R7
;---------------;-----------------------;
; subroutine code here			;
;---------------;-----------------------;
	mov	a,result		; subroutine passes the result back to the calling routine in Reg A
;---------------;-----------------------; if the calling routine wants to recover its Reg A, use direct addressing: mov a,16h
Line4:	mov	psw,r7		;2b2c	; restore the calling routine's flags and register bank from the subroutine's R7
	ret	;-----------------------; RB#0 is now active
		; RB#0 Ram Addresses	; NOTE: none of these registers are changed by the subroutine.
		; RB#0+R0->00h  [ ]	;
		; RB#0+R1->01h  [ ]	;
		; RB#0+R2->02h  [ ]	;
		; RB#0+R3->03h  [ ]	;
		; RB#0+R4->04h  [ ]	;
		; RB#0+R5->05h  [ ]	;
		; RB#0+R6->06h  [ ]	;
		; RB#0+R7->07h  [ ]	;
		;-----------------------;
In Line4 above, the saved image of calling routine's PSW flags and RB is restored by register addressing from R7.


SCENARIO #2: . . . Having a Interrupt Service Routine assign itself a Register Bank:

Interrupt Service Routines (ISR) are different than subroutines as they can be invoked anywhere, and when an ISR returns, the environment must be seemingly unchanged by the interrupt. That means flags, register values and register banks in foreground should be restored before the ISR returns control to foreground.

In this scenario we'll assume that RB#{0,1,2} might be in use from various places in foreground, and that RB#3 is reserved for this critical interrupt.

The priority task for the ISR getting a Register Bank (RB) is:
(1) Save the psw flags and RB selection before changing the RB# or Reg A. Use direct address 1Fh=RB#3+R7.
(2) Save Reg A for the calling routine only it its necessary. Use direct address 1Eh=RB#3+R6
(3) Select the RB#3 for the subroutine.

In the following code example, the ISR will use RB#3. The foreground can be restored by register addressing from R6:R7.

In Line1 below, PSW is saved by direct addressing into 1Fh=RB#3+R7.
In Line2 below, Reg A is saved by direct addressing into 1Eh=RB#3+R6.
In Line3 below, the ISR selects RB#3.
		;-----------------------;---------------; one bank among RB#{0,1,2} is now active in foreground
		; RB#{0:2} Ram Addresses		; NOTE: none of these registers are changed by the subroutine.
		; RB#{0:2}+R0->{00h,08h,10h}  [ ]	;
		; RB#{0:2}+R1->{01h,09h,11h}  [ ]	;
		; RB#{0:2}+R2->{02h,0Ah,12h}  [ ]	;
		; RB#{0:2}+R3->{03h,0Bh,13h}  [ ]	;
		; RB#{0:2}+R4->{04h,0Ch,14h}  [ ]	;
		; RB#{0:2}+R5->{05h,0Dh,15h}  [ ]	;
		; RB#{0:2}+R6->{06h,0Eh,16h}  [ ]	;
		; RB#{0:2}+R7->{07h,0Fh,17h}  [ ]	;
		;-----------------------;---------------;
ISR+Register_Bank:			; for clarity, interrupt enable/disable code is removed
		;-----------------------; the following saves the foreground for restoration before 'reti'
Line1:	mov	1Fh,psw		;3b2c	; save foreground's psw by direct address of 1Fh=RB#3+R7
Line2:	mov	1Eh,a		;3b2c	; save the foreground's Reg A by direct addressing of 1Eh=RB#3+R6
Line3:	mov	psw,#18h	;3b2c	; select RB#3, if the ISR requires the foreground's psw flags, use r7's image
		;-----------------------;
		; RB#3 Ram Addresses	; RB#3 is now active, with R7 and R6 already loaded with restoration values
		; RB#3+R0->18h  [ ]	; RAM byte available to the ISR
		; RB#3+R1->19h  [ ]	; RAM byte available to the ISR
		; RB#3+R2->1Ah  [ ]	; RAM byte available to the ISR
		; RB#3+R3->1Bh  [ ]	; RAM byte available to the ISR
		; RB#3+R4->1Ch  [ ]	; RAM byte available to the ISR
		; RB#3+R5->1Dh  [ ]	; RAM byte available to the ISR
		; RB#3+R6->1Eh  [Reg A]	; foreground's Reg A stored here
		; RB#3+R7->1Fh  [PSW]	; foreground's PSW flags and Register Bank selection stored here
;---------------;-----------------------; the ISR's RB#3.R0:R7 RAM bytes don't affect the foreground
; interrupt service routine code here	;
;---------------;-----------------------; now fully restoring foreground:
Line4:	mov	a,r6		;1b1c	; restore foreground Reg A from R6
Line5:	mov	psw,r7		;2b2c	; restore foreground flags and register bank from R7.
	reti			;	; foreground register bank is now active, return from ISR
		;-----------------------;---------------; foreground is fully restored
		; RB#{0:2} Ram Addresses		; NOTE: none of these registers are changed by the ISR.
		; RB#{0:2}+R0->{00h,08h,10h}  [ ]	;
		; RB#{0:2}+R1->{01h,09h,11h}  [ ]	;
		; RB#{0:2}+R2->{02h,0Ah,12h}  [ ]	;
		; RB#{0:2}+R3->{03h,0Bh,13h}  [ ]	;
		; RB#{0:2}+R4->{04h,0Ch,14h}  [ ]	;
		; RB#{0:2}+R5->{05h,0Dh,15h}  [ ]	;
		; RB#{0:2}+R6->{06h,0Eh,16h}  [ ]	;
		; RB#{0:2}+R7->{07h,0Fh,17h}  [ ]	;
		;-----------------------;---------------;
In Line4 above, the foreground's Reg A is restored by register addressing from R6
In Line5 above, the foreground's PSW flags and RB is restored by register addressing from R7

[Updated on: Tue, 24 October 2023 19:45]

Report message to a moderator

Reply to Questions about the '90s Project, Proof of Concept design... [message #10452 is a reply to message #10442] Thu, 05 October 2023 09:52 Go to previous messageGo to next message
jayindallas is currently offline  jayindallas
Messages: 110
Registered: June 2021
Senior Member
Questions & Answers Regarding the 90s Project
lynchaj wrote, "Do you have the design information for your POC design? Schematics, EDA files, etc.? If it's just some parts obsolescence issues, they could probably be designed out and bring your POC back to life as a retrocomputer board. Then others could enjoy it too. Do you have any photos? Please post if available"

Answers for some of the questions above, about what was used to build the board set:
I don't think the PoC assembly has much use as a dev-board because its too purpose-built and used SMT where possible.

For the PoC and Alpha Production versions, I designed the boards with "Pads" 'PowerLogic' and 'PowerPCB' CAD software for the PC.

For the Alphas, I used TurboCAD Profesional for metal work, The aluminum cases were vendor-purchased. I designed the mounting stand and the panel cutouts in TurboCAD. It was also used for some stamped metal brackets it needed. I also used TurboCAD to make a 3-D model of the entire assembly to confirm that it fit together as designed. The Alphas designs were a tight fit in their aluminum case.

The PoC board was a set of 3 snap-off boards, I think all the Alphas were 6-layers because it was designed to pass EMI testing and handle static electricity. The HMI and main board were 2.25 x 3.75 inches. The third snap-off board was the 8051 serial in-system programming card measuring 2.25 x 3.125 inches. No metal-work for the PoC. It was powered at +5Vdc @ 1.5 amps on the main board, fed by parasitic DC voltage from 8 to 48 Volts. The 8051s had 64K of internal eerom and ram space; no external memory was required. Software bit-banged I/O as an I2C bus for RTC, internal temperature sensor, and huge datalog storage; a coin-sized battery kept the RTC running when the vehicle parasitic power was removed for charging. It had a capable relay for wiring an external alarm. The Philips 8051 is a 44-pin PLCC mounted on a SMT pad.

Proof-of-Concept boards: (1) PoC HMI-card with components, (2) without.
. . . (1) . . . /forum/index.php?t=getfile&id=2900&private=0 . . . (2) . . . /forum/index.php?t=getfile&id=2901&private=0
Above: The PoC HMI (Human Machine Interface) board. +5Vdc, 13-pin in-line interface. This included some throw-in LEDs to see if a hex circle could give useful relative direction from vehicle (Answer:NO) and whether the intensity display integrated inside the hex circle would be ok with cheaper LEDs (Answer:NO) and the HP pixelated 5x7 4-character LED chip x3 for twelve characters. Its a fast shift register interface through all pixels plus a load signal.

Alpha Production boards: Alpha HMI-card with components.
/forum/index.php?t=getfile&id=2903&private=0
Above: The Alpha HMI board. The complete assembly consisted of: +5Vdc 3Amax, TTL signal, 17-pin in-line interface. This missing components are for a IRDA circuit on the right, not required for the target product, but we sold this configuration and others, in various markets. The LED brightness control is a Micrel chip that is also controlled through the in-line interface. The Alpha service spares mostly have 8 pixaled alpha-numeric chars installed. If we needed to replace a 12 char board, we'd just solder an additional 4char chip.

[Updated on: Thu, 26 October 2023 13:28]

Report message to a moderator

Re: Reply to Questions about the '90s Project, Proof of Concept design... [message #10453 is a reply to message #10452] Sun, 15 October 2023 18:52 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
jayindallas wrote on Thu, 05 October 2023 12:52

The User-Interface Boards Might have a Hobbyist Use:
On PoC and Production-Alpha assemblies, one snap-off board is a User-Interface (Display/ID Badge/Menu Buttons). Those original UI boards were all LED technology as they were the most rugged choice back in the day. They might be something for Arduino/RPi/Hobbyist/Protoboarding projects, as the interface is TTL signal +5Vdc, single inline connection, (PoC: 13pins, Production-Alpha: 16pins).

The Production-Alpha User-Interface boards has:
1). A large 3-digit+decimal green numeric display.
2). A 10 LED segment, intensity bar displays, 4-green, 4-yellow, 2-red, left to right.
3). A 12 or 8 char green, 5x7 pixelated HP LED comprised of 4 chars per chip. Software can animate various char scrolls.
4). Two 80db piezo buzzers for an alarm.
5). Two pushbuttons (waterproof buttons with panel-mount seal).

I do have some bare board PoC User-Interface cards I wouldn't mind dumping on EBay. Likely have some old LEDs in our prototype parts inventory to match up as a kit. The Micrel LED current controller chip is likely unubtainium; maybe some stock?
Hi
This weekend I ordered some SAB80535 dev board PCBs. They should arrive in about 2 weeks or so. Please send me a PM with your address and I will send one.

Your User Interface boards could probably be adapted to the SAB80535 dev boards. They sound like they'd be a good addition.

Thanks!
Re: Reply to Questions about the '90s Project, Proof of Concept design... [message #10465 is a reply to message #10453] Sun, 22 October 2023 08:00 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
I've order some of the SAB80535 dev board PCBs and they should be here soon.

If you'd like to help in the initial build and test (always exciting!) please contact me and I will send you a PCB.

Thanks, Andrew Lynch

[Updated on: Tue, 24 October 2023 03:42]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10467 is a reply to message #10428] Mon, 23 October 2023 11:28 Go to previous messageGo to next message
ale500 is currently offline  ale500
Messages: 44
Registered: April 2018
Member
At work we have several lines of sensors with 8051s inside, a custom core that does most opcodes in 2 clocks and some in 4 like jumps and movx. We program mostly in C, sometimes I drop (I see is as an improvement) to assembly for a bit of speedup. Underrated how many of these uC are getting produced daily, no royalties help Smile. We pay for ROM and RAM, and EEPROM, though Smile
Nice to see that not everything is Z80 and 68 K, even if I love those two Smile
Re: Intel 8051 MCU dev board, revisited [message #10468 is a reply to message #10467] Tue, 24 October 2023 03:51 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
https://github.com/lynchaj/duodyne/blob/main/SAB80535-Dev-Bo ard/SAB80535-Dev-Board.jpg

Hi, these are the PCBs on the way. I think they'll be here this week. So far, there are me and two others in the initial build and test team. I am focused on getting the hardware working but then my focus will move to software.

One of the nice things about 8051 being so common is there are some good free/open-source compilers and assemblers for it. I am thinking SDCC looks appealing. What tools are you using for your projects? Any recommendations?

Thanks, Andrew Lynch

PS, I've been thinking about some interesting (to me) applications for the SAB80535 dev board and decided to work on a project that's been in the back of my mind for a long time. It's a completely free/open-source EPROM programmer and TTL/CMOS chip tester. Yes, they've been done before but it interests me and I think there is declining support especially for the legacy NMOS EPROMs (of which I have many). With all the cheap fake junk on the IC market these days, a reliable TTL/CMOS chip tester is more important than ever.

What applications do you think would be interesting?

[Updated on: Tue, 24 October 2023 03:57]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10470 is a reply to message #10468] Thu, 26 October 2023 11:14 Go to previous messageGo to next message
ale500 is currently offline  ale500
Messages: 44
Registered: April 2018
Member
At work we use IAR and SDCC. SDCC produces a bit longer and slower code but we use for testing and regression. Production is done with IAR. It has very neat optimizations and tries very hard to produce small code, sometimes gets big in the way. Doing small simple functions helps a lot.
A while ago, as I have many AT98C2051 and AT89C51s, I started a proof of concept project, can I do a space invaders look alike using the UART as input/output device ? and only 2 K of code ? I may dig it up (packed in some box since I moved). They are kind of simple devices with short manuals, something one can understand fully.

I like your project idea: a TTL Tester (with a real 5 V device). I did one using a PiPico and some level shifters, at least I could determine that the 74LS181 in skinny dip package I got from aliexpress are genuine even if they are the HC version and repainted as LS.

[Updated on: Thu, 26 October 2023 11:19]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10471 is a reply to message #10470] Sat, 28 October 2023 16:24 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
I have one maybe two SAB80535 dev board PCBs for anyone who would like to join in the initial build and test. I will send you one of the PCBs for free. Sorry, US only. The boards are small and cheap and the shipping outside the US is prohibitive -- more than it takes to make new boards. The Gerber files are available on the GitHub if you'd like to make your own PCBs too.

Thanks, Andrew Lynch
Re: Intel 8051 MCU dev board, revisited [message #10473 is a reply to message #10471] Sun, 29 October 2023 13:41 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
One SAB80535 dev board PCB left. If you're in the US and willing to help out on the initial build and test send me your shipping address and I'll send you a board.

Thanks, Andrew Lynch
Re: Intel 8051 MCU dev board, revisited [message #10482 is a reply to message #10473] Thu, 02 November 2023 16:15 Go to previous messageGo to next message
scruss is currently offline  scruss
Messages: 62
Registered: December 2015
Location: Toronto, Canada
Member

For general recent 8051 things, I've used WCH's CH552 with SDCC. While it's not through-hole, there are some breakout boards that are sort-of DIP sized. One of them is WeAct Studio's CH552 Mini Core Board: decently made, and very cheap.


The CH552 has 16 K flash, 1280 bytes RAM and typically runs at 24 MHz.


> Does anyone know what each of the pins on the 6502 CPU chip in the Apple II Plus does?
They all plug into the socket on the motherboard to keep the chip from drifting away. - c.s.a2 FAQ of yore
Re: Intel 8051 MCU dev board, revisited [message #10517 is a reply to message #10482] Mon, 27 November 2023 04:17 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
This weekend I finally got to build my SAB80535 dev board and am testing it now. I did find one serious problem but it is easily fixed by cutting an exposed trace.

I have one PCB left if anyone would like to join in. This is a fun project! Thanks, Andrew Lynch

PS, free board and shipping to those in the US. For those outside the US, it is cheaper to just order your own PCBs from the Gerbers on the GitHub repository. Sorry, blame expensive post-COVID shipping rates!
Re: Intel 8051 MCU dev board, revisited [message #10523 is a reply to message #10517] Fri, 01 December 2023 18:50 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
More testing on the SAB80535 dev board. Found another design problem but came up with a work-around fix. The good news is finally got a "LED blink" program to run. Learning a whole bunch about 8051!

Tomorrow's goal is to geta "scream" type program running and test out the serial interface.

I still have one PCB left if anyone would like to join in the build and test! thanks, Andrew Lynch
Re: Intel 8051 MCU dev board, revisited [message #10525 is a reply to message #10523] Sun, 03 December 2023 05:17 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
Some good news on the SAB80535 dev board; the "scream" program is working and that tells us a lot about what is working on the board. The debugging adventure so far is I've found fake 74LS373s (replaced), discovered the SAB80535 pin 37 (Vbb) is different than on the SAB80C535 (trace cut, problem fixed) and that I used the wrong crystal oscillator (was: 22.1184 is: 11.0592). I am temporarily using 6.0000 MHz crystal until my replacement crystals show up.

Please do me a favor and if you are interested in the SAB80535 dev board, even if you don't plan to build one, please sign up for GitHub and "watch" the project.

Go to this link: https://github.com/lynchaj/duodyne and click on "watch" in the upper righthand corner. Then you can see duodyne discussion, ask questions, make requests, etc.


Thanks, Andrew Lynch

PS, got the PPIs initialized and working. Here is a video of the LEDs blinking. PAULMON2 is running and I can execute programs from RAM. Much nicer than reprogramming the Flash ROM

https://github.com/lynchaj/duodyne/blob/main/SAB80535-Dev-Bo ard/Test-Programs/20231203_132808.mp4

PPS, lesson learned is that for the next prototype don't use PLCC-32 for Flash ROM socket. A real pain to remove and replace. Use a ZIF DIP-32 instead. Didn't think that one through well enough.

[Updated on: Sun, 03 December 2023 11:55]

Report message to a moderator

Re: Intel 8051 MCU dev board, revisited [message #10527 is a reply to message #10525] Tue, 05 December 2023 04:08 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
The SAB80535 dev board seems to be coming along nicely. PAULMON2 is adapted to the new hardware and running fine. I can make simple programs using SDCC for C and AS31 for assembler and download them using PAULMON2 Intel Hex download feature.

Last night was able to get the Flash ROM in-circuit update working which should reduce the amount of remove, reprogram, and replace cycles on the Flash ROM. It turns out that the 39SF040 uses nearly the same erase and reprogramming algorithm as the 39SF512 with the only difference being the chip ID.

Tonight, I am going to test out TinyBASIC and see if I can get that to work. Next will be the 16x2 LCD interface.

Thanks, Andrew Lynch
Re: Intel 8051 MCU dev board, revisited [message #10535 is a reply to message #10527] Thu, 07 December 2023 06:01 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi
Well, mixed results with the Tiny BASIC testing. I think it can work but the system configuration settings need adjustment. The PJRC version assumes it is running in ROM whereas on the SAB80535 dev board it is running in RAM. Some adjustments are needed in the code to make it work properly. It partially works with the minor changes I've made but stil something is not quite right. I think it is related to the storage of the code and/or variables. I can type in a short BASIC program and can use LIST to see it and even RUN to execute it but clearly something is still wrong because every attempt to RUN ends in a WHAT? error message. If you want to take a closer look, the code can be found here:

https://www.pjrc.com/tech/8051/contrib/tb51/tb51.asm

I switched over to testing the 16x2 LCD display and initially the results were quite promising. After careful configuration of the interface and putting Kapton tape under the LCD to prevent inadvertent shorts, I tested with the sample code and it worked flawlessly. The LED backlight lit up and it looked great. However, on subsequent attempts, the LCD was non-responsive and even the board would not boot if the LCD was left in the board interface. I did eventually get it to boot again but the LCD is totally non-responsive. There are only 14 pins in the interface, and they are fairly basic signals like D0-7, A0, A1, CS, and an Enable plus VCC and GND. Like a 6800-style interface. I've been searching for a root cause but nothing yet. I suspect it may be a case of infant mortality but that's hard to prove.

Thanks, Andrew Lynch
Re: Intel 8051 MCU dev board, revisited [message #10537 is a reply to message #10535] Thu, 07 December 2023 19:36 Go to previous messageGo to next message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Nope, the LCD displays are fine. Just plain operator error. I was starting the LCD display test program from the wrong location. Once I realized my error, the LCD displays work fine.

That's good news! Andrew Lynch
Re: Intel 8051 MCU dev board, revisited [message #10550 is a reply to message #10537] Thu, 21 December 2023 06:26 Go to previous message
lynchaj is currently offline  lynchaj
Messages: 1080
Registered: June 2016
Senior Member
Hi

I am applying the lessons I learned during the build and test of my SAB80535 dev board to a new V1.1 version. Adding a bunch more IO devices and trying to rearrange things into an improved layout.

The new board will have I2C, a Z2 MMU, SD, USB, RTC with battery backup, 8-bit DAC sound, speaker, input switches, output LEDs, settable configuration in and out ports, and an OLED display.

/forum/index.php?t=getfile&id=2970&private=0

The board is larger and that allows for a much richer array of IO devices. Also reconfigured the GPIO into better organized IDC ports. Added a lot of diagnostic LEDs and pins to connect your logic probe. Replaced the annoying PLCC-32 Flash ROM with a DIP-32 ZIF. Should make updating the Flash ROM much easier. However, the Flash ROM can be updated in-circuit which really reduces the need to remove and replace the device.

Not sure when I am going to order these PCBs but hopefully fairly soon. If anyone has ideas for the dev board please let me know or post here.

Thanks, Andrew Lynch



[Updated on: Thu, 21 December 2023 06:33]

Report message to a moderator

Previous Topic: Parallel Printer (SPP) Emulator Shield
Next Topic: Rosco M68K builders


Current Time: Tue Jul 15 11:58:23 PDT 2025

Total time taken to generate the page: 3.10976 seconds