W65C02S, Z80, 80C31 or other legacy processor?

Ah, yes. It was possible to produce ROMable Z80 (though I think not

8080) code with TP (3.0, no?). Back in the last millenium, I did a Z80-based motor monitor instrument wot had all the firware written in TP.
Reply to
Spehro Pefhany
Loading thread data ...

I still have an original Applied Microsystems Z80 emulator that worked that last time I used it (10 years ago?). Fully static and wonderful for helping in hardware debug.

I'd part with it for some amount.

Scott

Reply to
Not Really Me

I think it might be interesting to look at using the Z80 and customarily associated peripherals (which seemed to be the 82xx series more than zilog's intended I/O companions), static ram, battery backed static ram masquerading as eprom, etc, but to also to have in mind the option of replacing some or all components with a pin and dimensions compatible plug in emulator module consisting of an SMD FPGA or CPLD or modern memory device, both as a backup plan for shortages, and in order to enable additional features. For example, a modern flash memory emulating an eprom, with a switch to do bank switching between multiple virtual 27xxx's. Or maybe able an RS232 or USB connection so that an external computer can be used to change the memory contents.

I also think that you should build in a "disk drive" based around an SD card. You should be able to write (bitbang) spi-mode drivers for that run on your actual Z80 or whatever, its really not very complicated. Especially if you used a sort of linear journaling file system (don't permit any erasing), since you have more space than almost any application on such a small system could consume.

Reply to
cs_posting

Do you need to design one specifically, or find one with your requirements.

Reply to
Gary Peek

Selected, highly-motivated first-world kids in the general vicinity of middle school age. It is to be assumed that they do not have another computer. The nature of the project is such that using a modern chip natively is preferable to using a vintage chip in emulation

Reply to
Steve at fivetrees

Followup: I presented the customer with some options, and we discussed the contents of this thread as well as my own personal biases.

The outcome of this meeting was that we both like the 6502 instruction set, but there are some practical problems with using the raw 6502, or in fact any of the non-integrated microprocessors. Among them is the need for rather a lot of external logic, or a CPLD, and/or relatively expensive

So it has been tentatively decided to use two micros.

- an ATmega8 as the display generator

-- 40x24 text

-- 80x48 graphics

-- NTSC and VGA so it can be connected to classroom projectors

-- also drives 7-seg LEDs for displayless monitor operation a la KIM-1

- an ATmega128 running the main program

-- 32K RAM on external memory buses

-- BASIC interpreter

-- optional CHIP-8 interpreter

-- 6502 emulator

-- 6502 machine language monitor

-- onboard hex keypad

-- PS/2 keyboard interface

-- SD card slot

-- serial port is a possibility

-- other I/Os required by the application

Both of these will be presented as black boxes ("CPU" and "display chip") for the purposes of the text. The idea being that if we have supply problems or want to improve performance, we can swap out the microcontroller transparently.

In particular we're worried about the NTSC and analog VGA outputs, as both these standards are moribund.

So Vladimir, it turns out one of your suggestions was the best to date.

Reply to
zwsdotcom

That makes sense, the 6502 has too few microcontroller choices.

This would seem to be the weakest link. Do you expect any GreyScale or Colour from this ?

Smarter to forget the LEDs and make a better Display engine, for less total cost ?. I'd suggest a 32KB Serial SRAM + Small CPLD with Frame Sync timing from Master

No USB ? - USB comes almost for free, and allows fast, intuitive driver-free access. Any other interface and you open things to being lost/forgotten. USB also doubles as power, aka the new Cellphone standard.

The Mega128 is also long in the tooth...

An AT32UC3B1128 will give you 32K SRAM on-board, and USB, and MUCH more grunt, for a rather similar price. Atmel also claim to have "UC3D series is a cost reduced option" due soon, (but with 16K SRAM?).

(AVR32 seems to have more SRAM in smaller packagers, and cheaper +USB than ARM alternatives )

Lots of low end and second hand TVs will have NTSC / PAL inputs, and analog VGA is not going away, as a lot of systems convert it.

-jg

Reply to
-jg

No, monochrome only. We anticipate it will mostly be used in the displayless mode anyway because in a classroom environment if they can't afford PCs for every student, they can't afford TVs or monitors for every student either. Main reason for the NTSC/VGA is so the instructor can show onscreen what he's doing, though it will also permit the child to experiment with more advanced projects at home.

What do you mean "better" exactly? And how is a CPLD plus an external RAM cheaper than a single > - an ATmega128 running the main program

The serial interface would be wired as DTE, not for talking to computers but for talking to other peripherals. This is *not*, as repeatedly stated, a device that is intended to connect to a PC or otherwise belong to a PC ecosystem in any way. If anything needs to be transferred (primarily firmware upgrades), it will be copied on SD cards.

BTW, I'm also not willing to inject USB horror into the development timeline for this (your definition of fast, driver-free and intuitive being apparently antonymal to mine) - I don't have the experience nor any tools to probe and debug USB malarkey effectively, so in any case the only viable solution for USB connectivity would be a canned USB- serial chip.

Well, true, but I see no evidence that it's going out of production anytime soon. The 1280/1281 would be fine too. Anyway since we are going the emulation/interpreter path we can upgrade as necessary without even having to change the documentation...

Bleck, ptui! If I go 32-bit it will be with ARM, not AVR32. Too wacky, still not a credible architecture IMHO (and likely never will be). We can buy a Cortex-M3 part for under a dollar now.

I should probably point out, the reason for the external SRAM is not because we need extra space, but because we want to use the external address/data busses and show them operating. I doubt very much any program more than a K or so will ever be run on this hardware.

I haven't seen any TV set without NTSC inputs to date, but I assume they are coming sooner rather than later. Of course, I don't USE TV sets at all (I loathe television), and I am far too poor to waste money on consumer electronics or cable TV subscriptions, so I don't follow the technology closely :)

Reply to
zwsdotcom

Lewin, since you are considering the idea of black boxes of a CPU and display (taken as "abstract chips," I gather), it makes your thoughts regarding Tiny BASIC all the more manifest. Tiny BASIC itself is designed to run on a simple, intermediate "language" and fits the vision you are talking about well -- it seems like an excellent choice. I hadn't understood that vision at the outset, but seeing better now your direction I can see also the better fit for purpose of a BASIC built on an IL, like Tiny BASIC.

It looks to me that you've got a clear perspective on direction. Thanks for exposing some of the thinking here.

Jon

Reply to
Jon Kirwan

That's a very important feature, this has to be capable enough to capture a kids imagination. It also has to avoid them outgrowing it too fast.

I was looking at Digikey prices in similar columns, and serial SRAM + CPLD is ~ 60-80c more than the $2.05 Mega8, (ie less than the 7Segs LEDs ) and WAY ahead in display capability. 4bits / pixel - certainly RGB (SCART/VGA) capable - still looking into if NTSC/PAL.Colour fits ?

Probably yes, but I also gave myself the challenge of both PAL/NTSC with one crystal my wish list, and Monochrome is OK with that caveat, but I fear the colour would be less tolerable from a common crystal. (it's already poor with NTSC) RGB colour is doable.

No reason not to make this Global :)

Not if you keep the pin-count down - that imposes a firm, natural ceiling to any 'creeping featurism' ;) What makes this viable, is really the new serial So8 SRAMs.

I was talking from the user's perspective, I know it's more work at this end...:)

Most USB uC have a FlashDrive demo board, surely ?

Like this ?

formatting link
OS/DOC/html/index.html

The thing only needs to be dumb-enough to look like a flash Drive (at least initially...), so teachers can get quickly homework, and kids can share projects...

True, but you are picking a worse place on the price/performance curve.

Not with 32K RAM and USB ;)

That's a lot of HW cost, for a rare feature. A Hex or ASCII Dump to the screen, would show similar 'animate' feedback. Even better would be an actual Quasi-DEBUG ability that animates in the source code

Of course, a nice display with at least GrayScale would help here... :)

- See how many things get simpler/cheaper when you have a better display ? [ Syntax Highlighting Text Editor is another example..]

-jg

Reply to
-jg

Perhaps we have better sourcing, or at least different... the mega8 is a bit less than $1.00 in 30pc qty for us. I'm sure in the millions both parts are more or less free, but not at these volumes.

60Hz composite video would be viewable on most PAL TV sets with a composite input. I doubt the associated teaching materials will be very palatable to non-USAians, though.

Oh my God! Not satisfied with the horror of a HID (which is where I thought you were going), you advance one further circle of hell inwards to a MSD? The reference implementations are only tested with Windows, if that, plus this introduces further issues such as what happens when the user says "format this drive" in some non-natively- FAT OS. All in order to duplicate functionality which can much more usefully be provided by providing the teacher with an SD card reader, especially since we have already decided to include the SD port.

There Shall Be No USB. Absent significant up-front compensation, I am never again going to allow myself to be put in a position where I have to answer a question that begins "I installed the latest version of {Windows,MacOS,Linux}, and...".

... neither of which are needed for the application. That price is for

16KF/4KR which would be just barely enough, I think, though it has no external memory bus so this would need to be simulated. The $1 price does not include a singing goldfish, either.

However it is an explicit requirement. Automotive airbags are also rarely used, but included by customer demand (where "customer" =3D "the government").

Qualitatively different. It does not show the data flowing and the buses (control as well as data and address) toggling during the act of reading and writing data.

These suggestions are turning the device into a general-purpose computer or peripheral and stuffing more and more functionality below the waterline, relying on complex UI features, and so forth, all of which is antithetical to the purpose of building this thing in the first place, which is to have a physical piece of hardware that is easily understandable (at the block level, anyway) and inspectable wherever possible using physical probe points.

Reply to
zwsdotcom

For $1, we can source a 6502 with 16K OTP ROM, 24 bits I/O. You can use the I/Os for an external bus or driving LCDs (20x4 or x8). Unfortunately, the version we are using cannot run code on the I/O ports. However, they do have another version (more expensive) with real external bus, in addition to the 32K internal SRAM.

Yes, it does. It has a 12bits D2A sound generator.

Reply to
linnix

What price is "more expensive" / volumes ? Does that still have ROM ?

-jg

Reply to
-jg

Sunplus? Winbond? I did consider them, but not COTS enough.

Reply to
zwsdotcom

The processors you are talking about have no internal memory, just registers and you have stated that it is a requirement to have external, addressable memory. When you exclude "emulation", does that include hardware emulation in a CPLD or FPGA? There are flash based devices that could be programmed to be cycle compatible with any of a number of processors. There is even a lot of IP on opencores.org. I'm not sure if you have considered this approach or not.

I believe there may even be some adequate CPLDs in DIP packages.

Programmable logic could do a lot with your peripherals as well. The composite video could be done with minimal external hardware and without sucking up all the CPU cycles as was done in the Sinclair ZX Spectrum.

Would this be along the lines of what you are looking for?

Rick

Reply to
rickman

Certainly sounds like special sourcing. Who is actually selling 30pcs for sub $1 ?

Only if they were Dual PAL/NTSC capable - but anyway, PAL monochrome is not a big jump Why would the teaching material be non-portable ?

More of an issue is VGA, which is a good idea, but was off my list due to a much higher ideal dot clock. Could get 32 chars across, at a 2 bit pixel, (64 Ch with 1 bpp) with some system Sw impact ? - might make the cut...

Point taken, but this model is what most cameras, and MP3 players use.

- and there are many mllions of those...

Anyway, SD gives you a safety net ? - and someone else can do the USB drivers... you are open-sourcing this ?

but how will you actually achieve that ? Mega cannot execute from RAM, so you can only show data fetch, but data access will be too fast on WRN/ RDN, so you need then additional sw-emulation to slow the bus way- down, so that users can see the lights. (ie you have really built a large SW LED driver)

The idea is good, but wasting HW (and PCB area/cost) to achieve this is not. Think about how many teaching-minutes will be used on this feature ?

With 128K & three emulations, it is already going to be complex :).

The idea is to make it look simple, and _also_ make it usable in a longer term by students.

ie Stretch the age group that can use it

-jg

Reply to
-jg

I have to ask. I think is around $2 to $3.

Yes, 16K OTP.

Reply to
linnix

I have the vendor's name bookmarked at work, but it is a Chinese OEM that is already buying the parts for use in other applications. I know Atmel's production qty price is considerably lower still.

I used to live in a PAL country, and when I left (1999) all of the sets were capable of so-called "PAL-60" with a large majority also being capable of autodetecting actual NTSC with either 3.58 or 4.43MHz color.

It's only a jump of software in fact, I wouldn't have much trouble tweaking the display controller firmware for this purpose.

Can't get into that in detail, yet. Suffice it to say that it is specifically written and intended for a US audience and might possibly be perceived as jingoistic to foreign readers. Of course, there's no reason why it couldn't be translated.

I've done the gfx resolution I describe in an MSP430F2012, at VGA syncrates (driving a "virtual" 640x480 display). Don't think I will have trouble with it on an Atmel CPU. I will use the SPI peripheral to output pixels, so the core only has to service 1/8th the data rate, with no shifting or masking necessary.

The host will use sync signals to determine when it's safe to send the next byte of command data. You've just reminded me, though, of the reason I was going to use async serial as the interface between the two rather than SPI - I'm already using SPI for video output, and I need a hardware-buffered interface obviously, since the display controller can't bit-bang anything while it's outputting display data.

This ground is very thoroughly trodden; if you google for "AVR VGA" or "AVR NTSC" you will see several such projects though unrelated to mine.

... and I myself have several Chinese MP3 players that won't enumerate properly on some operating systems. Grrrr.

It's the intention. It might get messy if we have to include some third-party IP, the client is still looking at that. Would very much not want to have binary blobs in the product.

Exactly, but as I tried to point out in my summary email (I guess I didn't state it explicitly...) the user will not "know" this is an AVR, the CPU will just be "CPU" and the accessible APIs will be the

6502 machine language monitor and BASIC interpreter - plus CHIP-8 if I can manage it.

See above. Single-step down to the machine cycle level is a software feature only since it's all emulation.

Not unless the user intentionally breaks the "encapsulation". By which time I would say they have graduated with flying colors!

Reply to
zwsdotcom

It was my preference to avoid it, but if you look a bit further in this thread I've decided to go down the emulation route because of various issues such as the cost of adding peripherals to a raw micro system. Mainly as a matter of experience and preference I will be using microcontrollers rather than CPLDs/FPGAs.

Reply to
zwsdotcom

This one has hardware ICE in native 6502 mode.

If you are talking about 3000, we would be able to build it for you. Qty 30 would be too expensive for NRE.

The problem is programming the beast. 30 pads are needed for parallel OTP programming. We are planning to mount it on a special PCB with 132 Bare Pad Array (0.1" pitchh) and connect it with a special pogo test adapter

more spec on this:

Fully static 65C02 compatible

32KHz or 500KHz/8MHz 16K OTP ROM 32K SRAM 56 I/Os Nand Flash controller USB 2.0 controller STN LCD/OLED controller Four channel 8 bits sound generator 12-bit DAC UART SPI
Reply to
linnix

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.