EASy68K  
It is currently Tue Oct 24, 2017 7:52 am

All times are UTC




Post new topic Reply to topic  [ 72 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject:
PostPosted: Fri Nov 09, 2012 3:20 am 
Offline

Joined: Fri May 14, 2010 3:17 am
Posts: 25
Location: Colorado
Quote:
I would not go to the bother to make a 6821 work-alike - I value my "spare time" too much to put the required effort (design, debug, document) into making a copy of a chip I can just buy for $6 (or less).


I understand your sentiment. However, I'm not just comparing the cost of an old GPIO chip, but the cost to "glue" an old chip to the 68K bus. If the plan is to use the 68008 in the 48-pin DIP with no VMA (which is all I have), or a newer 68K without E, VMA, and VPA, there'll need to be some extra work done to glue a 6821 or 6521/22 anyway. Also, I have a vague recollection the 6821 registers are dynamic, and will forget their values without a constant E signal. If so then it *needs* a synchronous clock signal just to keep the 6821 functional.

I'm thinking of a 6821 work "similarly" that's 68000 bus compatible. If that turns out to be not much work then maybe I'll add extra register addresses for setting and clearing individual bits of the port(s) without using read/modify/write instructions, similar to the ColdFire "Rapid GPIO."

The microcontroller idea also has merit, though, especially because of the extra peripherals you're likely to get for free.

Quote:
Consider the higher pincount (40+) PIC16 and PIC18 variants that have the "Parallel Slave Port" peripheral.


I don't want to start a holy war, here, but a PIC!? No thank you. I own nothing PIC I could use. I'd have to learn PIC. For me, at least, I think the CPLD idea would be less time and effort than using a PIC.

You can get an ARM Cortex-M0 or M3 part for $1.00 - $4.00, which is what I'm now used to working with, and I also have a few drawer's full of AVR tools and chips in my office. Those would be my preferences for a microcontroller-based solution. I also know Freescale S08 well, and have tools for that line. S08 is not really that great at the bit-bang and hardware work-alike type stuff, but you have to admit there'd be something pretty neat about having some Freescale silicon on the PCB alongside the 68K.

Having tasted low-level programming with the 32/16-bit ARM Cortex-M, though, It's hard to have to go back to 8-bit AVR or PIC or anything else (after all, isn't the whole processor-with-many-32-bit-registers-and-no-segmented-memory thing why most of us started liking the 68K to begin with?)


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2012 1:49 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
Consider the higher pincount (40+) PIC16 and PIC18 variants that have the "Parallel Slave Port" peripheral.

I've had a look at the PIC PSP amd it only provides a single 8 bit port that can respond to a read or write cycle like a peripheral device. I don't think a single port is quite enough to reproduce the EASy68K hardware functionality as a number of addresses can be written to and/or read. I think this would need a corresponding number of ports or an addressable port of some kind.

Not to say that the PIC can't do it, just that the PSP feature doesn't help that much.

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2012 1:14 pm 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
lee wrote:
Quote:
In fact, I'm considering some sort of PIC to provide analog input, SPI mastering, and PS/2 keyboard input.

Perhaps you could add an SD card slot for transfering software from a PC host


Lee, re: SD card slot; you've read my mind. More on the PIC later (I think I hit at least a couple nerves with the reference to PIC).

Quote:
...and an LCD port to complement the PS/2 keyboard. That would give you a device with at least text I/O without requiring it be tethered to a host.


Here, I've got other plans - I've scrounged a few TI TMS9918 and Yamaha V9938 video display processors, I'll use one of those for video output. These VDP chips are very nice for SBC applications because the display memory is not mapped into processor memory space. Rather, it is accessed through the VDP I/O register space. A hit in terms of throughput, sure, but it's a snap to connect these VDP chips to just about anything with an external bus (real or 'faked').

I have to confess that I've not done a very good job of seeing how well these VDP chips would support the Sim68K graphics features. I suspect fairly well, with a number of limitations.

Quote:
I already have a lot of the 68K side software done in a BIOS that supports just about all the text I/O calls and has trace capabilities with disassembly and register display or modification. Not exactly like running code in SIM68K but pretty close I think.

You also get S record and flash ROM support as well as EhBASIC built in.


That sounds awful nice, Lee - is that sort of like a monitor, or just the trap support for trace/disasm/etc.? I think a monitor is a must, and of course there's always TUTOR (after hacking for the 68681 DUART for terminal I/O).

EhBASIC is one of the things that got me excited about a 68K SBC, truth be told. My "vision" is an SBC is somewhat along the lines of a retro "home computer": can boot into EhBASIC, perhaps run CP/M 68K (I have a bit of experience with CP/M 80, but nothing with CP/M 68K) and well-supported by the cross-IDE Easy68K.

-tom


Last edited by TomCircuit on Sat Nov 10, 2012 3:51 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2012 2:13 pm 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
maalper wrote:
...I'm not just comparing the cost of an old GPIO chip, but the cost to "glue" an old chip to the 68K bus. If the plan is to use the 68008 in the 48-pin DIP with no VMA (which is all I have), or a newer 68K without E, VMA, and VPA, there'll need to be some extra work done to glue a 6821 or 6521/22 anyway.


"glue cost" is pretty low, especially in my case - as I mentioned earlier, I'll use a CPLD. I'm using a DIP48 68008, also, so I'm in the same boat as you, Mark.

Quote:
Also, I have a vague recollection the 6821 registers are dynamic, and will forget their values without a constant E signal. If so then it *needs* a synchronous clock signal just to keep the 6821 functional.


Fortunately, this is not the case: both the Moto C6821 and WDC 65C21 datasheets indicate that the respective parts are capable of static operation.

The 6821 can be interfaced to the 68K through either synch or asynch interfaces and it doesn't matter to the memory map one bit. So, for our DIP48 68008 systems, we could use the synch interface that's present on the chip (generating VMA with a trivial amount of glue logic). On a 68020+ system, it will have to be interfaced via the asynch interface and appropriate DSACK0/1 control.

Quote:
I'm thinking of a 6821 work "similarly" that's 68000 bus compatible. If that turns out to be not much work then maybe I'll add extra register addresses for setting and clearing individual bits of the port(s) without using read/modify/write instructions, similar to the ColdFire "Rapid GPIO."


Nice idea, Mark, and I fully agree that the direct set and clear capabilities of modern GPIO are lovely :-) Your CPLD-based 6821 superset sounds interesting. Go for it!

Quote:
The microcontroller idea also has merit, though, especially because of the extra peripherals you're likely to get for free.

Quote:
Consider the higher pincount (40+) PIC16 and PIC18 variants that have the "Parallel Slave Port" peripheral.


I don't want to start a holy war, here, but a PIC!?
[...snip...]


I agree, let's not quibble over which uC's are more horrible than the others, etc. I've suffered through most of the ones you listed, and a few others.

I'll address my comments towards I/O processing in a subsequent post.

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2012 3:33 pm 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
On the topic of I/O processing:

I see a few distinct types of I/O for an Easy68K compatible SBC.

A) the memory-mapped Sim68K 'hardware' - 8 digit LED display, 8 discrete LED, 8 toggles, 8 pushbuttons, int trigger stuff.

Early in this thread we concluded that HW I/O would be nice as an "add-on" to the SBC, but we didn't want to dedicate PCB real-estate to every SBC to have these features. I stand by this conclusion - bring the data bus, a handful of address bits, and one/more decoded 'hardware' signal(s) to a connector and call it a day. The int triggers and auto-int stuff could be implemented as-is, or simply limited in scope (e.g. DIP48 68008 doesn't support all 7 INT levels). In either case, the necessary INT signals would have to be present on said connector.


B) custom I/O that isn't natively supported by Easy68K

the 6821 PIA falls into this category. It doesn't exist in Easy68K. We just wing it :-)


C) the I/O that is implied by the Sim68K TRAP 15 functions - graphics, sound, network, file, serial, etc.

Here's where it gets interesting! A lot of this stuff could be very involved to implement on an SBC. In other words, you really have to "want it" to justify the effort to get it. Network needs a NIC. File I/O needs some sort of storage subsystem. Graphics needs a display subsystem. etc.

Minimally, we've agreed that some sort of serial I/O to a host is a requirement, and we can meet that with a DUART, which in turn can be abstracted through TRAP 15. Is this the substitute for Text I/O? Or for Serial I/O? Neither? Both? I'm not sure...your thoughts?

Beyond that, there's wilderness:

I wrote a bit about the display subsystem I'd like to implement (TI TMS9918 or Yamaha V9938). Of course, in that case, I'd do my best to get some degree of Easy68K compatibility. For the most part, any sort of graphics is an LSI (be it 9918, 6845, Propeller, FPGA, etc.).

If I have video, I want/need a keyboard. PS/2 KB is the obvious choice, but of course a custom KB is possible with the right TRAP support.

Sound is a completely different area, and here my intentions diverge completely from sim68K compatibility (and likely everyone else, also). In my case sound will be via MOS 6851 SID chips and, therefore, is clearly "B" hardware.

For storage, I personally have NO desire to resurrect old mechanical FDD units and vintage FDC chips. (Been there, done that with the N8VEM Z80 CP/M project). An SD card and some FAR support seems infinitely more appealing and practical to me.

Some of the native Sim68K features make sense to implement through a uC-based I/O processor (IOP). In my opinion, the following are good candidates:

SD card interface
RTC interface
PS/2 keyboard interface
Analog Inputs
Analog (DAC or PWM) Outputs
SPI mastering
I2C mastering

Sim68K implies that the first two items on this list (SD, RTC) exist - the third item (PS/2 KB) is nice if there's also video. The remainder would be "B" (custom) hardware, yet easy to provide with most modern uCs.

How to interface the uC IOP to the 68K? Lee commented that a PIC PSP is a painful solution to memory mapped uC-based I/O due to the single address I/O port. Mark barely avoided vomiting at my mere mention of a PIC :-) In order to keep things uC "agnostic", I think it's important to choose an interface that is both present on most uC and well supported by the 68K. That rules out SPI and I2C (icky on 68K), and memory-mapped (icky on most uC). An asynchronous serial interface to the uC IOP as a possible solution. We've got a spare UART channel on the 68681 DUART, just begging to be used...

An async interface to the IOP could be quite extensible - one could use a uC with USB host capability and support thumb drive; or a uC with CAN bus, etc. Also, allows IOP functionality to be placed on its own PCB very easily, if that is helpful.

A small protocol between the IOP and the 68K would need to be worked out, to handle the exchange of things like keypress info, date/time, and file IO.

Your thoughts?

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2012 4:18 pm 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
A follow-up: I'm waffling on the SD file I/O being on the IOP or directly on the 68K. It could be as simple as a 3.3V Input and Output port pair, and the 68K does the bit-bashing for the SD SPI. OTOH, if the SD is inside the IOP, and the IOP uC is fast enough, the serial transport of file sector data might not be so bad.

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2012 6:56 pm 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Here's the notes and help text from my BIOS and flash utilities

Code:
*************************************************************************************
*                                                                                   *
*     BIOS for EPAC 68008 V0.52 2012/11/06                                          *
*                                                                                   *
*     Sim68K TRAP #15 calls, status and comments                                    *
*                                                                                   *
*     0 to 20, text/time/terminate                                                  *
*                                                                                   *
*      0    Supported                                                               *
*      1    Supported                                                               *
*      2    Supported                                                               *
*      3    Supported                                                               *
*      4    Supported                                                               *
*      5    Supported                                                               *
*      6    Supported                                                               *
*      7    Supported                                                               *
*      8    Supported                                                               *
*      9    Supported                                                               *
*     10    Not done                                                                *
*     11    Not done                                                                *
*     12    Supported                                                               *
*     13    Supported                                                               *
*     14    Supported                                                               *
*     15    Supported                                                               *
*     16    Supported - saves the value only                                        *
*     17    Supported                                                               *
*     18    Supported                                                               *
*     19    Supported - last key only                                               *
*     20    Supported                                                               *
*                                                                                   *
*     30 to 32, simulator functions                                                 *
*                                                                                   *
*     30    Not done                                                                *
*     31    Always returns d1.l = $00000000                                         *
*     32    Display hardware window ignored, else returns d1.l = $00000000          *
*                                                                                   *
*     50 to 57, file I/O                                                            *
*                                                                                   *
*     50    Always returns no error, d0.w = $0000                                   *
*     51    Always returns error and null FID, d0.w = $0002, d1.l = $00000000       *
*     52    Always returns error and null FID, d0.w = $0002, d1.l = $00000000       *
*     53    Always returns error and no bytes read, d0.w = $0002, d2.l = $00000000  *
*     54    Always returns error, d0.w = $0002                                      *
*     55    Always returns error, d0.w = $0002                                      *
*     56    Always returns error, d0.w = $0002                                      *
*     57    Always returns no error, d0.w = $0000                                   *
*                                                                                   *
*     60 to 68, run and trace, not Sim68K compatible, this will need changing       *
*                                                                                   *
*     60    Supported   display the registers                                       *
*     61    Supported   disassemble the instruction at (a1)                         *
*     62    Supported   task 60 then 61                                             *
*     63    Supported   execute user code from (a1)                                 *
*     64    Supported   execute user code                                           *
*     65    Supported   continue user code                                          *
*     66    Supported   trace user code from (a1)                                   *
*     67    Supported   trace user code                                             *
*     67    Supported   set supervisor state                                        *
*                                                                                   *
*     70 to 72, sound I/O                                                           *
*                                                                                   *
*     70    Always returns no error but no sound played, d0.w = $FFFF               *
*     71    Not done                                                                *
*     72    Always returns no error but no sound played, d0.w = $FFFF               *
*                                                                                   *
*     80 to 94, graphics I/O                                                        *
*                                                                                   *
*     80    Not done                                                                *
*     81    Not done                                                                *
*     82    Always returns black, d1.l = $00000000                                  *
*     83    Not done                                                                *
*     84    Not done                                                                *
*     85    Not done                                                                *
*     86    Not done                                                                *
*     87    Not done                                                                *
*     88    Not done                                                                *
*     89    Not done                                                                *
*     90    Not done                                                                *
*     91    Not done                                                                *
*     92    Not done                                                                *
*     93    Not done                                                                *
*     94    Not done                                                                *
*                                                                                   *
*                                                                                   *
*     Monitor commands:                                                             *
*                                                                                   *
*        help or ?  - display the help message                                      *
*                                                                                   *
*           [...]  - optional parameter                                             *
*            hex   - unsigned hex value                                             *
*             n    - single digit 0 to 7                                            *
*                                                                                   *
*        dn [hex]  - display or set the value of Dn                                 *
*        an [hex]  - display or set the value of An                                 *
*        us [hex]  - display or set the value of us                                 *
*        pc [hex]  - display or set the value of pc                                 *
*        regs      - display the saved user registers                               *
*                                                                                   *
*        ver         - display the version string                                   *
*        restart     - restart the monitor                                          *
*        load        - load an S-Record file                                        *
*        run [hex]   - run code from (pc) or [hex]                                  *
*        trace [hex] - trace code from (pc) or [hex]                                *
*        time [hex]  - display or set the system time                               *
*                      (centiseconds since midnight)                                *
*                                                                                   *
*        flash       - enter the BIOS flash utility                                 *
*                                                                                   *
*        dump [start[,end]]  - dump from start to end as hex and ASCII              *
*                                                                                   *
*        basic [end[,start]] - start EhBASIC, optionally specify the                *
*                              RAM end and start addresses in hex                   *
*        warm [start]        - restart EhBASIC, optionally specify the              *
*                              RAM start address in hex                             *
*                                                                                   *
*                                                                                   *
*     The built in flash utility has the following commands:                        *
*                                                                                   *
*        help   - display the help message                                          *
*                                                                                   *
*        ident  - identify and display the BIOS ROM                                 *
*        device - display the current device                                        *
*        clear  - fill the image memory with $FF                                    *
*        copy   - copy the current BIOS to the image                                *
*        flash  - write the image to the flash ROM                                  *
*        verify - compare the image with the flash ROM                              *
*        ver    - display the version string                                        *
*                                                                                   *
*        exit   - quit and restart the BIOS                                         *
*                                                                                   *
*     The following flash devices are supported                                     *
*                                                                                   *
*        AMD                                                                        *
*           AM29F010                                                                *
*                                                                                   *
*        Atmel                                                                      *
*           AT49x512    AT49x001xT  AT49x001x   AT49F002x                           *
*           AT49F002xT  AT49x010    AT29C512    AT29C010x                           *
*           AT29C020x   AT29C256/7                                                  *
*                                                                                   *
*        Mosel Vitelic                                                              *
*           F29C51002T  F29C51002B                                                  *
*                                                                                   *
*        PMC (Lucent)                                                               *
*           Pm29F002T   Pm29F002B                                                   *
*                                                                                   *
*        SST                                                                        *
*           29EE010                                                                 *
*                                                                                   *
*        Winbond                                                                    *
*           W29C020     W29EE011                                                    *
*                                                                                   *
*                                                                                   *
*     More 68000 and other projects can be found on my website at ..                *
*                                                                                   *
*      http://mycorner.no-ip.org/index.html                                         *
*                                                                                   *
*     mail : leeedavison@googlemail.com                                             *
*                                                                                   *
*************************************************************************************

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2012 7:20 pm 
Offline

Joined: Fri May 14, 2010 3:17 am
Posts: 25
Location: Colorado
Quote:
SD card interface
RTC interface
PS/2 keyboard interface
Analog Inputs
Analog (DAC or PWM) Outputs
SPI mastering
I2C mastering


Wow! You're shooting for the sky. But that's cool!

Quote:
Mark barely avoided vomiting at my mere mention of a PIC Smile


Hehe, that was my "toned down" response. You should've seen my original reaction. ;-)

Quote:
An async interface to the IOP could be quite extensible - one could use a uC with USB host capability and support thumb drive; or a uC with CAN bus, etc. Also, allows IOP functionality to be placed on its own PCB very easily, if that is helpful.


Well, I was thinking... if we're putting a uC on the PCB, maybe we could put a high pin count uC capable of master/slave operation over the 68K bus. Sure, it wouldn't be a blazingly fast interface, because whatever uC you pick probably has to software-generate some 68K bus control signals, but then the IOP *could* also bootstrap the PCB, program flash memory, etc.

Otherwise, yes, a serial interface would work. *If* there is a 68901 it has a USART as well, which could serve that purpose.

Another feature I'd like to see is a spare UART dedicated to debugging, and a GDB server stub in the BIOS to drive it.

It sounds like we're zeroing in on a base configuration for the mainboard. I'd like to discuss connectors and connector layout for support of add-on board(s). I'd suggest we need a spec for the layout, electricals, etc. of the expansion connectors. It sounds like we all want something a little different, here, but it'd be nice to spec. it so whatever we all "invent" can be passed on to each other in a usable way. Something sort of Arduino-ish, but for our 68K bus and signal lines.

Here's what I did on my prototype, just as a starter point for discussion:

Code:

All connectors are male IDC-style, 0.1"-spaced, 2xn headers.

J2 - 2x5 header - GPIO from 68901
+----+----+
|IO0 |IO1 |
+----+----+
|IO2 |IO3 |
+----+----+
|IO4 |IO5 |
+----+----+
|IO6 |IO7 |
+----+----+
|GND |+5V |
+----+----+

J4 - 2x8 header
+----+----+
| A0 | A1 |
+----+----+
| A2 | A3 |
+----+----+
| A4 | A5 |
+----+----+
| A6 | A7 |
+----+----+
| A8 | A9 |
+----+----+
|A10 |A11 |
+----+----+
|A12 |A13 |
+----+----+
|A14 |A15 |
+----+----+

J5 - 2x8 header
+----+----+
|A16 |A17 |
+----+----+
|A18 |A19 |
+----+----+
|FC0 |FC1 |
+----+----+
|FC2 |~AS |
+----+----+
|~ROM|~RAM|
+----+----+
|~USR|uVPA|  NOTE: uVPA is active high, and not the same as the CPU ~VPA. It
+----+----+        connects to the external circuit generating ~VMA diagrammed
|~VMA|N/C |        in the MC68000 User Manaul.
+----+----+
|GND |+5V |
+----+----+

J3 - 2x8 header
+----+----+
| E  |~BR |
+----+----+
|~BG |~DS |
+----+----+
|~DTACK|R/~W|
+----+----+
| D0 | D1 |
+----+----+
| D2 | D3 |
+----+----+
| D4 | D5 |
+----+----+
| D6 | D7 |
+----+----+
|GND |+5V |
+----+----+


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2012 7:41 pm 
Offline

Joined: Fri May 14, 2010 3:17 am
Posts: 25
Location: Colorado
Quote:
Fortunately, this is not the case: both the Moto C6821 and WDC 65C21 datasheets indicate that the respective parts are capable of static operation.


I was looking at a datasheet for MC6821 and while the part description does specify "Static Operation" the electrical specification also list a *minimum* E "cycle time" of 10 uS. To me that implies a minimum E frequency of 100 kHz, but it may just mean that the falling edge of E must follow a rising edge within 10 uS. I think the WDC65C21 doesn't list a minimum E cycle time, but I don't have that datasheet in front of me. Still, both parts *may* use E to synchronize other operations, such as sampling of I/O or control signal inputs. That's not clear to me from the datasheet one way or the other, but it's unusual for GPIO logic to put I/O inputs directly on the Data Bus without some syncrhonization, lest they change state in the middle of a bus cycle.

Since I have a 68K prototype I can certainly try connecting a 6821 both ways (synchronous with E, and asynchronous with a derived signal) and see what I get.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 11, 2012 5:21 am 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
lee wrote:
Here's the notes and help text from my BIOS and flash utilities
[...snip...]


:shock:

Good heavens - you've not left much for the rest of us to do, Lee! No, seriously, I'm beyond impressed.

So, I'm guessing from the description of the EPAC SBC on your (very nice) web pages that the Text I/O supported is that via a 68681 UART channel? If so, I think that answers the question I posed in one of my prior ramblings today.

Any indication of how many bytes your BIOS code (incl monitor/flash/EhBASIC), consumes as-is today? Again, judging from your EPAC pages, it fits within 128KB of flash? (I see two Atmel 29C010 in your Dual BIOS photo) In other words, are we going to be OK with 256K of flash?

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 11, 2012 6:22 am 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
maalper wrote:
I think the WDC65C21 doesn't list a minimum E cycle time, but I don't have that datasheet in front of me.

The 65c21 has a min cycle time spec (tCYC) of 70ns. I think you meant max cycle time, and yes, I just looked, and there's no max tCYC. So, I'm going to go with the assumption that the 65C21 is really "fully static".

Quote:
Still, both parts *may* use E to synchronize other operations, such as sampling of I/O or control signal inputs. That's not clear to me from the datasheet one way or the other, but it's unusual for GPIO logic to put I/O inputs directly on the Data Bus without some syncrhonization, lest they change state in the middle of a bus cycle.


For sure the 6821 uses E for all the fancy-pants handshake modes involving CA1/2 and CB1/2. That much is very clear from the Moto and WDC datasheets.

Quote:
Since I have a 68K prototype I can certainly try connecting a 6821 both ways (synchronous with E, and asynchronous with a derived signal) and see what I get.
That would be great if you're able to check this out, Mark, in order to get this aspect of the 6821 PIA nailed down once and for all.
That being said, I'm a bit confused - you DON'T want to use the 6800 interface for the 6821 PIA? Why not? Is it lack of VMA on the 68008? If so, don't let that stop you; VMA generation is trivial.

Quote:
Well, I was thinking... if we're putting a uC on the PCB, maybe we could put a high pin count uC capable of master/slave operation over the 68K bus.

I think there are plenty of opportunities for setup and hold time issues with this approach because of the two clock domains (uC and uP). This could be a nightmare to debug. Hence my highly technical assessment of "icky", earlier. This approach isn't very uC agnostic, either, I don't think.

Quote:
then the IOP *could* also bootstrap the PCB, program flash memory, etc.


Ah, you raise some gory details that are near and dear to my heart, Mark. Bootstrapping is indeed a concern, as it always is, unless flash is programmed externally first. I'm considering the idea of a socketed 27C256 EPROM, with a h/w jumper option to bank in over 32K of the RAM area, to aid in bootstrapping the flash - it can hold an S-record loader, or maybe even TUTOR. It'd be pretty simple to simply add a ROMSEL output, ROMBOOT jumper input, and glacial wait-states into the glue logic to accomplish this.

Quote:
Otherwise, yes, a serial interface would work. *If* there is a 68901 it has a USART as well, which could serve that purpose.

Another feature I'd like to see is a spare UART dedicated to debugging, and a GDB server stub in the BIOS to drive it.


I think you've found the use for the 68901 UART - namely GDB. I'd love for someone to show me the ropes on using GDB. Actually, I'd love even more for someone to de-mystify how to build GCC and libs for 68K running under DOS/win. I've tried and failed numerous times. My foo is obviously not strong enough. If our Easy68K SBC were to be supported by some free/open C compiler (e.g. GCC) that would be nothing short of wonderful.

-tom


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 11, 2012 6:43 am 
Offline

Joined: Mon Dec 27, 2004 11:40 pm
Posts: 318
Quote:
So, I'm guessing from the description of the EPAC SBC on your (very nice) web pages

Why thank you.

Quote:
that the Text I/O supported is that via a 68681 UART channel?

Yes, all I/O is via the same channel. I did toy with using the other channel for user program I/O but swapping the lead every time quickly became a pain.

Quote:
Any indication of how many bytes your BIOS code (incl monitor/flash/EhBASIC), consumes as-is today?

At the moment the whole thing fits in $626C bytes, something under 25K.

Lee.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 11, 2012 2:49 pm 
Offline
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1048
I have been following this discussion with interest. I am open to the idea of making additions to the EASy68K simulated hardware (PIA etc) in order to make it fully compatible with the resulting hardware.

There is also the possibility that I might be able to purchase 25 of these boards for use in my class. A board designed for classroom use must be (safe, reliable and student proof). I don't think it is necessary to duplicate all of the EASy68K hardware on the board. An isolated interface that the students can use to connect to a vector board would be perfect. I'll have them wire their own LED displays and switches.

_________________
Prof. Kelly


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 12, 2012 3:35 am 
Offline

Joined: Fri May 14, 2010 3:17 am
Posts: 25
Location: Colorado
@Lee, I checked out your page as well. I agree, very nice work! In particular I noticed your PRNG code (I noticed the ADD.L instead of LSL.L optimization, by the way), which tickled me because a couple of months ago I was helping a colleague with his PRNG and showed him how a Galios implementation made things more efficient. This was on an AVR, but I've also done it for the ARM. I've not gotten around to doing it for the 68000 series--and now I don't need to. :-)

Quote:
I'm a bit confused - you DON'T want to use the 6800 interface for the 6821 PIA? Why not? Is it lack of VMA on the 68008? If so, don't let that stop you; VMA generation is trivial.


The "energy" behind whether or not to use the E/VMA/VPA signals to interface to a 6821 (or something similar) is that there was some discussion regarding using a newer 68000 series part, or offering that as an option, and many newer parts (e.g. 68SEC000 and 68EC020) do not have *any* of the 6800 interface signals.

Regarding using a microcontroller as bus master for bootstrapping and/or extra I/O:

Quote:
I think there are plenty of opportunities for setup and hold time issues with this approach because of the two clock domains (uC and uP). This could be a nightmare to debug. Hence my highly technical assessment of "icky", earlier.


I think there's definitely potential for issues *if* they are designed in. I think the key to getting a uC to "play nicely" is to make good use of the 68000 asynchronous bus architecture. If the uC (of whatever flavor) asserts Bus Request and waits for Bus Grant (properly qualified by the 68k Data Strobe) before becoming bus master, waits for DTACK when it is master, and asserts DTACK when it is slave *after* it samples or drives the 68k data bus, then I think it will work just fine.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 15, 2012 4:39 am 
Offline

Joined: Wed Oct 03, 2012 6:24 pm
Posts: 24
Location: Detroit, MI
After the all wailing and gnashing of teeth re: MC68230 PIT devices, I ended up finding a reasonably priced source for them (Hong Kong). So, I'll have a few of those on hand, also. I bought four of them for $4 each, along with some other not-so-easy-to-find chips, from UTsource.net. We'll see how that turns out. I'm OK with sticking with the 6821 for parallel I/O on a "minimum system", but the more I read about the 68230, the more I thought it might be handy.

So, tallying up, here's what I've got in mind for a 68008 system. My "vision" is two PCB, "stacked" physically, some TBD board-to-board interface or perhaps just ribbon cable/IDC. My goal would be for the MAINBOARD to be as general purpose as possible, and then possibility of different MEZZANINE boards for different purposes.

Will need some sort of "expansion bus" for the mezzanine, and I'm still not certain about the partitioning, but this is what I've got in mind so far:

MAINBOARD:

MC68008 @ 8 MHz (OC to 10 MHz to obtain 1 MHz E bus)
512 KB SRAM (I will use a KM684002-12)
384 KB flash (I will use AM29F040, ignore/bank last two 64KB sectors)
128 KB EPROM (jumper option to bank into portion of RAM, TUTOR/flash utility)
EPM7128S glue (Altera PLCC84, CPLD 128 macrocell, JTAG, 5V)
--> DTACK mux/generation
--> BERR generation
--> VMA generation
--> IPL encoding
--> IACK decoding / VPA autovectoring
--> address decoding
--> RESET/HALT generation
--> 3-output/1-input port for SD card

MC68681 DUART (async bus, IPL = 7)
--> CH A via RS232 level shifter (e.g. MAX232A) or FTDI USB bridge
--> CH B to "I/O expansion bus" for PS/2,
--> 3x GPO to RGB LED (status indicator)
--> 3x GPO to DS1302 RTC RST/, SCLK, DO (via 74HCT125)
--> 1x GPI from DS1302 RTC DI
--> 4x GPI from DIP switch (boot into BASIC/flash, etc.)

MC68901 MFP (async bus, IPL = 5)
--> USART to ?
--> GPIO to ? (1x INT from VDP, 1x INT from ETH0)

MC6821 PIA (on E bus, IPL = 2, autovectored)
--> 8b PORT A to ? (probably just dual-row header of some sort)
--> 8b PORT B to ? (ditto)

SD card interface (async bus)
--> 3.3V SPI interface to SD card
--> 100mA 3.3V LDO regulator
--> 74LVC125 level shifter (5V --> 3V)
--> CLK, SS, SO data latch within CPLD
--> SI buffer (3V --> 5V) within CPLD

MEZZANINE:

2x MOS 6581 SID sound generators (on E bus)
--> L & R audio

1x Yamaha V9938 VDP (video processor, async bus, INT via MFP)
--> composite video output
--> 128KB DRAM (4x 4464)

1x PIC16F876 IOP (via DUART channel B)
--> bit-banged PS/2 keyboard interface
--> 4x analog inputs
--> 4x PWM analog outputs
--> I2C bus master

(?) 1x W5100 Ethernet MAC+PHY (async bus, INT via MFP)
--> indirect interface

I'm interested in thoughts from anyone following this thread - as I mentioned before, I expect that many of us will have different physical implementations (due to different parts availability, peripheral blend, etc) but my goal is that we can all use the same BIOS to harness the power of EASy68K compatibility.

-tom


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 72 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

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:  
Powered by phpBB® Forum Software © phpBB Group