small 68020

[norwestrzh]

Here is a small footprint version of a 68020. It is quite similar to the small 68000 shown previously in this thread (Home Brew Computing). It has 2 MB SRAM, 64k EEPROM, 68681 DUART (2 serial ports, one is the console @ 38,400 k), and a compact flash interface via an 82C55 PPI. It is currently running at 25 MHz on a gold top 68020RC16E. I have tried a number of 25 and 33 MHz CPU's but 25 MHz is the fastest that I can get out of any of them. It runs CP/M 68k with sixteen 8 MB "disk drives". In experimenting with this design, I found that the bus timing for the 68020 is very different than the 68000/010. I didn't want to tangle with dynamic bus sizing, so it is locked to 8-bit. Performance is still very good.

Roger

 

[norwestrzh]

I've discovered that enabling the cache on my small 68020 gives a significant performance boost to running CP/M 68K. I guess that shouldn't come as any big surprise? Most applications run without a problem, but it appears that COM2X (the 8080 emulator) doesn't work with cache enabled. That's a big disappointment because I use it to gain access to a number of legacy 8080 programs, such as editors (WordMaster for example). I'm working on a little CP/M 68K program to query the cache status and enable/disable it from the command line. Still experimenting.

BTW, I see pretty much the same behavior on Plasmo's very excellent CB030 (68030).

Roger

 

[norwestrzh]

Turns out that no matter what the state of the user/supervisor bit in the status register at start-up, CP/M 68k forces user mode:

00019b78 : 2f08 MOVE.L A0,-(A7)
00019b7a : 40e7 MOVE.W SR,-(A7)
00019b7c : 0257 0700 ANDI.W #$0700,(A7)
00019b80 : 4e73 RTE

The AND mask should be $2700 to preserve the user/supervisor bit. When I made that change, CP/M 68k did all sort of strange things. So I gather that CP/M 68k only wants to run in user mode. Why? I doubt that anybody who uses it runs in a multi-user environment.

Roger

 

[u8002]

So I gather that CP/M 68k only wants to run in user mode. Why? I doubt that anybody who uses it runs in a multi-user environment.

System vs. user mode is about protecting system (CP/M) integrity.

I guess your problems stem from self-modifying code, which doesn't rhyme well with caches. Your best bet would be to add a BIOS function that disables / enables the cpu cache, and write a little tool that makes the call. Does CP/M 68k support RSX?

 

[norwestrzh]

>> System vs. user mode is about protecting system (CP/M) integrity.

Well, sure. On a multi-user system, you don't want one user corrupting the system and blowing other users out of the water, or fooling around with another user's application memory. On a single user system, I would assume that it is that user's responsibility to assure that bad things like that don't happen. In any event the only one impacted by bad behavior is that that user him(her)self!

>> Your best bet would be to add a BIOS function that disables / enables the cpu cache

Yes, but enabling/disabling cache is a protected operation. CP/M 68k calls that little routine (posted above) that puts the CPU into user mode. Once that is done, returning to system mode becomes problematic. I tried to change the mask used in this little routine to preserve the system/user status, but as I said, all kinds of strange things started to happen. I have not had the opportunity to go back to this and try to determine what was going on. AND, more importantly, is it really worth the effort?

>> Does CP/M 68k support RSX?

I have no idea. I've used RSX with CP/M Z80 (V.2.2), but have never tried it with CP/M 68K.

Roger

 

[jlang]

I would think that CP/M 68k was never expected to run on a 68020.

 

[norwestrzh]

>> I would think that CP/M 68k was never expected to run on a 68020.

Maybe so, but it works quite well on a '020. *smile* I noticed that turning on cache gave a performance boost (no mystery there, I guess) in the monitor when copying or zeroing large blocks of memory, so it got me thinking about trying to enable cache for CP/M. That opened up a whole can of worms!

Roger

Oh, and it also runs quite well on the '030, using Plasmo's CB030 SBC. I'm thinking about trying a similar experiment with the '040!

 

[u8002]

>> Your best bet would be to add a BIOS function that disables / enables the cpu cache

Yes, but enabling/disabling cache is a protected operation.

That's the idea - don't the BDOS calls work by calling a system trap? That would switch to system mode, and your bios routine coudl then toggle cache use. When the BDOS call returns, it supposedly switches back to user mode.

 

[norwestrzh]

>> That's the idea - don't the BDOS calls work by calling a system trap? That would switch to system
>> mode, and your bios routine coudl then toggle cache use. When the BDOS call returns, it
>> supposedly switches back to user mode.

Yes, BDOS calls are via TRAP #3 (I think). Exceptions run as "system" as well (I think). So it would probably work to enable/disable cache that way. BUT, that little four line function (cited above) gets called multiple times (I think -- haven't traced it out completely), so CP/M wants to run in user mode. When I changed the mask used, so that the user/system bit is preserved, CP/M started doing all sorts of strange things. The end result is that I didn't want to mess with it anymore. It will take somebody smarter than I am to figure out why CP/M doesn't like cache enabled.

Roger

 

[Rene_bdm]

>> That's the idea - don't the BDOS calls work by calling a system trap? That would switch to system
>> mode, and your bios routine coudl then toggle cache use. When the BDOS call returns, it
>> supposedly switches back to user mode.

Yes, BDOS calls are via TRAP #3 (I think). Exceptions run as "system" as well (I think). So it would probably work to enable/disable cache that way. BUT, that little four line function (cited above) gets called multiple times (I think -- haven't traced it out completely), so CP/M wants to run in user mode. When I changed the mask used, so that the user/system bit is preserved, CP/M started doing all sorts of strange things. The end result is that I didn't want to mess with it anymore. It will take somebody smarter than I am to figure out why CP/M doesn't like cache enabled.

Roger

Hi Roger. Just a few weeks ago, I was able to buy this 1985 HP 64700 Emulator with 68020 POD, and Trace Analysis card. I used to work woth HP64000 back in 1985, this 64700 model came just after the series of 8 bit PODs like 6502, 6809, Z80m 68000. Looking for a nice little 68020 test board. Is yours for sale or schematics ? Regards René. Netherlands

 

[norwestrzh]

Hi Rene,

As a matter of fact, I do still have a few boards. I'm not terribly proud of this 68020 variant because I sidestepped the complications of the dynamic bus, and locked it at 8-bits. It works, and is surprisingly fast. I didn't expect that it would perform very well. I have one running (CP/M 68K) at 25 MHz.

I'd be happy to send you a bare board. I wonder what it would cost to the Netherlands?

Roger

BTW -- it uses the PGA form factor for the '020 -- would that work OK with the POD?

 

[Rene_bdm]

Hi Rene,

As a matter of fact, I do still have a few boards. I'm not terribly proud of this 68020 variant because I sidestepped the complications of the dynamic bus, and locked it at 8-bits. It works, and is surprisingly fast. I didn't expect that it would perform very well. I have one running (CP/M 68K) at 25 MHz.

I'd be happy to send you a bare board. I wonder what it would cost to the Netherlands?

Roger

BTW -- it uses the PGA form factor for the '020 -- would that work OK with the POD?

Hi Roger. That's super cool. Yes, the socket is PGA (114?). If a bare board fits in an envelop, it would just be a few stamps. Just let me know how much for 68020 board and mail cost and you can send me me a PayPal request. Will check for my userid. I work by the way for www.gaminglabs.com testing gaming machines with hardware and Software debugging. For 24 years with GLI and since 1983 in computers. What a Journey. A friend from me is building a KIM-1 replica (6502).

 

[MiaM]

Nice card!

A few comments:
IIRC the CPU switches stack pointers when changing between user and supervisor mode. Thus you would use the supervisor stack when running user programs if you don't switch to user mode, and maybe either the supervisor programs assumes that the stack is in a particular area (sounds like a bad idea, but who knows) or more likely the supervisor stack is too small.

You could use any of the free TRAPs to add a routine that changes the cache state and returns to the user mode program. Or for that sake you could add a handler to the privilege violation TRAP (not sure what the actual name is) and see if a user program tries to change the cache settings, and if so just do the change for the user mode program, and return.

Q: Is there a particular reason for having the CF card on an 8255 PIO?
It's not that hard to connect a CF card / IDE disk directly to a 68000/68020 bus.
You could for example look at the schematics for the Amiga 600, 1200 and/or 4000.
Tip: If you swap D0-D7 with D8-D15 the data stored on disks/cards will be compatible with content stored using a PC.

 

[norwestrzh]

You are 100% correct. The stacks switch when in supervisor mode. I forgot about that. I need to experiment some more with switching to supervisor mode. As I remember, I was able to use the undefined opcode interrupt to enter supervisor mode. (that's any opcode that has $A as the first byte.)

Yes, there is a reason for using the PIO to interface the CF to the 68020 bus. I've had all kinds of problems with a direct interface - particularly with the 68000. So, I just skipped attempting a direct interface with the '020. Maybe I shouldn't have done that? The 68020 bus timing seems to be very different than the 68000? Also, various vendors of CF modules seem to play fast and loose with the interface. I've had very different results with different CFs -- at least with the 68000. Got to look at how the Amiga does it, I guess.

Roger

 

[MiaM]

This is just a guess but I would think that if you wait a moment before activating _DTACK (or whatever the equivalent is called on the 020) to make the bus cycles longer when the CF card is addressed then it would probably work.

Related anecdote: About 25 years ago or so I created a simple IDE interface intended for an Amiga 500 (at a time when vintage stuff were cheap, so I soldered it directly to the pins of a 68k CPU, LOL). It worked for the most part, but oftenly the disk wouldn't properly increase the counter for read words, so by using the status register to tell when a sector is read rather than just read 256 words I would sometimes end up doing 257 reads. I'm 99.9999% sure that this was due to me only having super slow 74C00 gates. (Can't remember where I got those, probably some type of surplus shop). Never got around to try faster chips.

Edit: Btw something that I found confusing is how 68k assemblers treat SP and A7, but I have to admit that I never really examined what op codes each of them generate.

 

[norwestrzh]

Yes, I corresponded with a guy from Norway who was quite interested in the 68000. He built a prototype that used a monostable multivibrator to extend IDERD* and IDEWR* (I think that's right). The capacitance in his circuit was tricky to calibrate so it was somewhat unreliable.

I've also experienced something like your 257 reads, but in my case 255 of the data bytes were correct and that last byte was garbage. Frustrating.

As far as I know, the 68K assemblers I use equate SP and A7. Either reference does the same thing, BUT as you pointed out, in supervisor mode either SP or A7 point to a completely different stack. I wonder if some of my efforts with supervisor mode were pointing at a poorly defined stack or one that didn't exist?

Roger