EASy68K  
It is currently Tue Oct 17, 2017 9:26 am

All times are UTC




Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Fri Dec 23, 2016 6:27 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
Hello,
I'm new to this forum. I'm a retired hardware engineering with experiences in the 68000 CPU family, mostly 68020 and 68040. I purchased a large box of salvage boards a decade ago and now have the time to rework them and repurpose them for my home projects. It is a 68302-based SBC with 1 megabytes of static RAM and 3 banks of flash memories (256K, 1meg, 1meg). It has a 68692 dual serial device and a 82C55 programmable peripheral. It was originally made by ADC Telecom and used as a controller in their Soneplex product line. I made a couple programming heads that can take over their bootflash and replace with my own bootloader, so at this point I have full control of the boards and able to do a couple projects like LCD display and Xbee-based temperature monitoring stations.

I'm looking for project ideas for these boards. I know I can use a better real time scheduler than my homemade one. Is uCOS the way to go? My own monitor/debugger is pretty crude so a better debugger would be really nice. As a hardware engineer, I did most of my diagnostic software in assembly language, but I know most people wants C, so how do I go about loading C objects on this board? These are just my thoughts, I love to hear what y'all may suggest. Thanks!

Picture of my board...let see if I know how to upload a picture here.


Top
 Profile  
 
PostPosted: Sat Dec 24, 2016 12:15 am 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
Here is a picture of the board. It measures 4-3/8" by 9"

Attachment:
File comment: 6-layer pc board
adc mpu_component side_F2.jpg
adc mpu_component side_F2.jpg [ 234.79 KiB | Viewed 2444 times ]


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 1:34 pm 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1048
The Tutor monitor program from the Motorola Educational Computer Board (MECB) is available on the Examples page. It might be fun to try to get it working on your board.
http://www.easy68k.com/easy68kexamples.htm

_________________
Prof. Kelly


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 7:12 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
Thanks for the suggestion. I'll try the Tutor. I dimly recall using it (I think a version of it was on the EXORmac in the early 80's), it'll be fun to resurrect it on the 68302.

My roll-your-own debugger does not use Trap calls. I like the idea of using trap calls to decouple the software from the underlying machine. It is also a great way to insert software simulation of hardware features as you've done with the Sim68K. So I'm also looking into replacing my I/O routines with EASy68K's trap services. About the trap services: the help page on EASy68K listed the various services under different topics (Text I/O 0-25, Mouse I/O 60-62, Serial 40-43, File I/O 50-59, Graphics 80-96, and sound 70-77). Are these the complete list of trap services? Should be enough works there for several long winters :)

PS, I'm geeky enough to appreciate setting long word alignment with org (*+3)&-4, but I can just about hearing your students complaining. :lol:


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 9:18 am 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1048
It is difficult to get the students to appreciate a good assembler hack :)

_________________
Prof. Kelly


Top
 Profile  
 
PostPosted: Sun Jan 01, 2017 5:57 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
Happy New Year 2017!

I've had a fun week puttering among hardware and assembler. Managed to get Tutor running on the repurposed 68302 board. I have to do a little bit more than just adding the trap 15 tasks (5,6, and 12 are called by Tutor). On start up Tutor initializes the vector table and overwritten the trap 15 vector, twice. Furthermore, the 68302 has special registers from $F0 to $FF that need to be initialized differently. So I made modification to INITVECT routine to skip over $F0-$FF and INITVMSG to leave trap 15 vector alone. Since I load the Tutor as S records using my own debugger which has a 10-millisecond timer interrupt service, I also need to mask off my timer interrupt. Lastly I installed the trap 15 vector just before the first EASy68K trap 15 call (turn off keyboard echo).

All these descriptions translate to just a few lines of code, but it force me to scratch the surface of the Tutor code and it is impressive! What it can do with 14500 bytes of program is amazing. It even has an one-line assembler and disassembler. It also bring back old memories--I've definitely used Tutor before. I still remember the ";DI' switch for assembler and disassembler, and I still hate the "MD" (Memory Display) command that really should be DM (for Display Memory), which, in fact, is what I use for my own debugger.

A screen shot of few tutor commands running on the re-purposed 68302 SBC.

Attachment:
File comment: Example tutor commands running on repurposed 68302 SBC
TUTOR.jpg
TUTOR.jpg [ 120.41 KiB | Viewed 2404 times ]


I probably will modify Tutor so it is callable by a foreground scheduler, so the debugger can monitor other tasks while they are running. Trap #15 task7 is a good task for that. And I'll definitely change DM command to MD. :lol:


Top
 Profile  
 
PostPosted: Sun Jan 01, 2017 6:03 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
Before I reinvent another wheel, maybe I should ask the question first: Before I go on and build my own hardware panel (the panel with 8x 7-segment displays, 8x buttons, 8x LEDs, 8x toggles switches and 7x interrupts buttons plus reset button), has anyone done it already? Is there an instruction for it? Thanks!


Top
 Profile  
 
PostPosted: Thu Jan 05, 2017 4:28 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
All the I/O signals from the on-board 82C55 is brought out to the 96-pin DIN connector, so a LCD daughter board can be added. The connector has no 5V power, so it is necessary to add a jumper from 5V to an spare pin.
Attachment:
File comment: Repurposed 68302 board with LCD daughter card
adc mpu with lcd board_F.jpg
adc mpu with lcd board_F.jpg [ 219.58 KiB | Viewed 2385 times ]


This LCD daughter card increases the overall length to about 15", rather unwieldy, so for specific applications, I just glue the LCD to a board and wire it directly to the 82C55.
Attachment:
File comment: Repurposed 68302 board with LCD panel glued on
adc mpu with glued LCD_F.jpg
adc mpu with glued LCD_F.jpg [ 213.45 KiB | Viewed 2385 times ]


I would rather build a DIN connector daughter board for the hardware 7-segments & push-button board, but it is a memory mapped device and there are no memory expansion capability through the DIN connector, so I'll need to glue it and wire the on-board bus signals to it. That's messy :cry:


Top
 Profile  
 
PostPosted: Sat Jan 07, 2017 2:14 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
I ran Lee Davison's MHz test and got 9.9MHz. I'm puzzled by the result. The board has a 16MHz clock and 16-bit wide data bus with zero wait state, so it is as fast as it can be. The number should be close to 16MHz. I double checked the 10ms timer function to make sure it is accurate. I programmed 68302's timer1 to generate an interrupt every 10ms and the timer1 interrupt service just increment a memory location. Task 8 of trap #15 just moves the memory location into d1.L. There maybe a small overhead due to the interrupt service, but that's once every 10ms, probably about 0.1% overhead.

When I add one wait state to memory access time, the result drops to 9.3Mhz. That's less than expected since 1 wait state stretches memory access from 4 cycles to 5 cycles, a 20% penalty. Instruction timing is not only limited by memory access alone, but still I expect a greater impact. In fact when I run the MHz test on the Tiny302 ( viewtopic.php?f=10&t=1574 ) which only has 8-bit wide memories, I got 8.1MHz for zero wait state and 7.3MHz for 1 wait state. That doesn't make sense to me.

Unfortunately Lee is not here to answer the questions. Anyone has insight into these results?


Top
 Profile  
 
PostPosted: Sun Jan 08, 2017 2:27 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
I delved into Lee's MHz program and decided it is unsuited for my particular case. What he tried to find out is the simulation speed of PC using the instruction cycle time of an ideal 68000 system which has 16-bit wide, zero wait memory. The unknown variables are simulation speed and trap emulation time so Lee used 2 equations to solve the two unknowns. In my cases there are additional unknowns of timer interrupt service routine, wait states and 8-bit wide bus. So the simple thing to do is just do a straight timing measurement using the timer on 68302.
68302 has 3 timers. One is a simple watchdog timer, the two others are flexible 16-bit timers. For this case they only need to be a free running timer of sufficient resolution. This can be set up with one command:
Code:
move.w #$F03,TMR2
which enable timer #2, use the system clock of 16MHz and divided by 16 so each count is equal to 1 microsecond, free-running and disable other unrelated features. Timer 2 is cleared in the beginning of the test and read at the end of the test. I simulate the code with EASy68K's instruction cycle time simulation to get the total cycle counts. Furthermore I added access to Flash in the beginning and end to trigger a digital scope for independent timing verification.
Here is the code: It unclear to me whether I have the "right" instruction mix, but what I have are a memory instruction, a register-register instruction, and test-and-branch instruction.

Code:
* use timer2 to perform timing measurement
* disable timer1 interrupt
*
         ORG    $1000
IMR      equ $FFF816       * interrupt mask register
TMR2   equ $FFF850   * timer2 mode reg
TCN2   equ $FFF856   * timer2 counter
START:                 
         move.w #$100,IMR    * only enable the serial port (console)
         move.w #$f03,TMR2   * enable timer2, use master clock, free-run, disable
         * interrupt, capture disabled, prescaler of 16
         * 1us per tick with 16MHz system clock
spin:
         move.b $600000,d4 * read flash, this is to trigger digital scop
    clr.w TCN2   * clear timer counter         
******* time measurement starts here ************
         move.w #$1000,d2  * d2 is the loop counter
         clr.w $2000       * clear a memory location
         clr.w $3000       * this is where final time value is stored
tstloop:
         add.w #1,$2000    * add to memory function
         move.l d2,d3      * register move function
         dbra d2,tstloop   * branch function
         move.w TCN2,$3000 * done, save end time to memory
**********time measurement ends here **************
         move.b $600000,d4 * read flash again to mark the end of test
         bra spin          * loop forever

         END    $0        * don't execute code after load


EASy68K simulation shows the total cycle is 122954 which rounds to 7685 uS at 16MHz system clock. Run the test on re-purposed 68302 as well as Tiny302 with zero wait, 1 wait, and 2 wait memory access:

Code:
          Tiny302 (8-bit bus)          Repurposed 68302 (16-bit bus)
0 wait    14858 uS                     7685 uS
1 wait    18444 uS                     9478 uS
2 wait    22031 uS                     11271 uS


So, zero wait 16-bit memory matches the simulated cycle time exactly. Adding wait state introduces about 20% penalty to performance. system with 8-bit wide bus is about half the performance of 16-bit wide bus.

(edit: Is there a way of doing tabulated table? Using code gets the job done, but it may be confusing to some)


Top
 Profile  
 
PostPosted: Sun Jan 08, 2017 4:28 pm 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1048
Plasmo wrote:
(edit: Is there a way of doing tabulated table? Using code gets the job done, but it may be confusing to some)

There is no way to do a tabulated table in the forum that I am aware of.

_________________
Prof. Kelly


Top
 Profile  
 
PostPosted: Mon Jan 09, 2017 3:08 am 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
profkelly wrote:
Plasmo wrote:
(edit: Is there a way of doing tabulated table? Using code gets the job done, but it may be confusing to some)

There is no way to do a tabulated table in the forum that I am aware of.

Thanks, Prof Kelley. Formatting a table as Code works for me.


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 4:29 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
One project I didn't expected to do was a flash programmer, but my 20 years old homemade programmer is becoming intermittent and it is time to replace it. One improvement is using a zero-insertion force socket so I don't have to pry the chip out with a screw driver which is probably why the old programmer is intermittent.


Attachments:
File comment: A programmer board glued to RAM array and wired into a repurposed ADC MPU board
Flash-programmer_stacked_F.jpg
Flash-programmer_stacked_F.jpg [ 254.53 KiB | Viewed 2262 times ]
Top
 Profile  
 
PostPosted: Fri Jan 27, 2017 9:46 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
This is the simplified version of EASy68K compatible display. Instead of 13 IC's, the simplified version has only 3 IC's. It is certainly a lot easier to handwire! The drawback is that it requires the microprocessor to refresh the display constantly since only one digit is displayed at any given time. In this implementation, the display is driven by the foreground idle task when processor is not doing anything. I kinda like that "drawback" feature because it indirectly shows the processor utilization--when the display starts to flicker, that means the processor is busily doing works. The power consumption is also significantly lower: it is about 150mA instead of 1 amp for the full-up display.

The program running on the display is Lee Davison's 'LED clock' taken from the example page.


Attachments:
backside_simplified_display.jpg
backside_simplified_display.jpg [ 549.95 KiB | Viewed 2187 times ]
simplifed display on repurposed 68302 SBC.jpg
simplifed display on repurposed 68302 SBC.jpg [ 652.39 KiB | Viewed 2187 times ]
simplified EASy68K display_r03.jpg
simplified EASy68K display_r03.jpg [ 413.85 KiB | Viewed 2187 times ]
Top
 Profile  
 
PostPosted: Sat Aug 12, 2017 8:45 pm 
Offline

Joined: Fri Dec 23, 2016 5:18 pm
Posts: 52
Location: New Mexico, USA
Porting CP/M68K to the 68302 SBC: ADC's spx-mpu has 3 banks of flash; the 2nd & 3rd bank are 1 megabyte each, enough to hold CP/M 68K v1.3 distribution files and more. Once I have CP/M 68K running in SIM68K (viewtopic.php?f=10&p=4833#p4833), I can map the RAMdrive to corresponding flash memory location of spx-mpu. Now I have the hardware equivalent of the SIM68K. SIM68K provides the visibility into what the hardware is doing.
Attachment:
cpm_on_mpu302.jpg
cpm_on_mpu302.jpg [ 176.59 KiB | Viewed 711 times ]


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group