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  |
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
|
|
|
|
|
|
|
Offer To Help 8051 [message #10436 is a reply to message #10434] |
Sun, 24 September 2023 10:06   |
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   |
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   |
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   |
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   |
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   |
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
|
|
|
|
PAULMON Updates [message #10446 is a reply to message #10442] |
Tue, 26 September 2023 13:02   |
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
|
|
|
|
|
A Tutorial on 8051 Register Banks. Update: 10/11 [message #10451 is a reply to message #10446] |
Thu, 05 October 2023 09:40   |
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   |
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) . . . . . . (2) . . . 
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.

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   |
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: Intel 8051 MCU dev board, revisited [message #10468 is a reply to message #10467] |
Tue, 24 October 2023 03:51   |
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   |
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 #10525 is a reply to message #10523] |
Sun, 03 December 2023 05:17   |
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 #10535 is a reply to message #10527] |
Thu, 07 December 2023 06:01   |
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 #10550 is a reply to message #10537] |
Thu, 21 December 2023 06:26  |
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.

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
|
|
|
Current Time: Tue Jul 15 11:58:23 PDT 2025
Total time taken to generate the page: 3.10976 seconds
|