DigicoolThings Forum

Totally agree on going down the ZIF path. I’ve got a whole container full of ZIF sockets, as I find them really useful.

I’m definitely planning on trying ROM writing, at some stage! On both the CPU card and the ROM Expansion Card. It’ll be a good educational exercise.

However, I always seem to be busy, and always many more project plans than I have free time. I intend on looking at SMON some more in the next week. The last couple of days I’ve been tied up with tax return time, and now I’m working on progressing my next YT video.
But, having lots of really interesting projects in the queue, is actually a good problem to have.

epaell wrote: ↑Sat Jun 29, 2024 9:19 pm Another, more involved option might be to set up a MAME equivalent of the MECB and make sure the code I'm burning works there before doing the actual burn. Perhaps something also worth playing with - though I'd have to admit that I somehow never find simulated systems quite as satisfying as the real thing

Ooh, that's not such a bad idea, you know... I have a couple of arcade machines right behind me here I could go full-contact MECB with arcade level joystick consoles!! Where's the arcade port section of the MECB forum, Greg??

In all fairness, if there were a MAME style emulator for testing pld and bios configs, that would indeed be cool! It'd certainly open up a speedy development toolset for trialling configs and software ports.

Also, since there's starting to be an expanding array of hardware and config combos and choices, would there be any worth putting together How-to articles somewhere on the forum? Maybe a getting started based on the MECB youtube videos/articles and a coherence on where "rev 1" started and how we are at "rev 27.2.etc.etc." and the achievements in-between that ought to be noted for newcomers? Maybe this is just doubling up on work already done? I'm thinking ahead to topics like "How to emulate Atari Consoles with MECB" or "Configuring your MECB to run Ancient XXX Title Software from XYZ Corp", etc. Thoughts? (not to hijack the thread, of course...)

bugeyedcreepy wrote: ↑Sun Jun 30, 2024 1:14 pm In all fairness, if there were a MAME style emulator for testing pld and bios configs, that would indeed be cool! It'd certainly open up a speedy development toolset for trialling configs and software ports.

I'm not really a fan of software emulation. FPGA hardware emulation is okay though, which is essentially what the Mister is.

I guess it's because of my early 8-bit microprocessor hardware design nostalgia, but I prefer to be running 8-bit microprocessor code on the original silicon chips. Without a real processor, the nostalgia aspect is a bit lost for me.

bugeyedcreepy wrote: ↑Sun Jun 30, 2024 1:14 pm Also, since there's starting to be an expanding array of hardware and config combos and choices, would there be any worth putting together How-to articles somewhere on the forum? Maybe a getting started based on the MECB youtube videos/articles and a coherence on where "rev 1" started and how we are at "rev 27.2.etc.etc." and the achievements in-between that ought to be noted for newcomers? Maybe this is just doubling up on work already done? I'm thinking ahead to topics like "How to emulate Atari Consoles with MECB" or "Configuring your MECB to run Ancient XXX Title Software from XYZ Corp", etc. Thoughts? (not to hijack the thread, of course...)

How-to articles would probably be beneficial.

In terms of getting started and MECB history, currently my Blog site posts pretty much gives the full history of my own progress, since I try to (eventually) make a video / post a blog entry, to cover most of my progress.

Speaking of emulating Consoles though, I've just this morning loaded up the PLD's and ROM and I currently have the really awesome "Attract mode" of the CreatiVision Console's "Sonic Invaders" running on the pixel-sharp TMS9928A RGBS output, complete with it's awesome SN76489 sound effects!

Of course, this isn't "emulation". This is a full recreation of the original hardware config on the MECB bus! With the same chips throughout, as running in an original CreatiVision Console of the early 80's.

Of course, I still can't play the games, as I still need to make a controller interface to plug into the PIA port on the Mototrola I/O Card.

But, I'm having an awesome time, with lot's of memories flooding back! Not to mention just how good the graphics look, compared to my old memories of a really noisey and artefact-filled RF TV picture, back in the day!

Speaking of emulating Consoles though, I've just this morning loaded up the PLD's and ROM and I currently have the really awesome "Attract mode" of the CreatiVision Console's "Sonic Invaders" running on the pixel-sharp TMS9928A RGBS output, complete with it's awesome SN76489 sound effects!

Awesome!

epaell wrote: ↑Sun Jun 30, 2024 11:44 pm Awesome!

Yeah! I’m supposed to be working on other things, but ever since I got the 6502 CPU Card up and running, getting some raw CreatiVision code running has been constantly on my mind. It’s great to prove it works, unchanged!

But, I’m now back to doing other stuff, before I get further sidetracked on controller interfacing.

I rejigged my PLDs and software so that it is now set up for 32KB RAM/ROM to test the FLASH writing. I initially had a great deal of confusion with this because I was trying to print out results with ASSIST09 but each time I entered a FLASH operation I think that disabled access to ASSIST09 (since it uses data bits to show status). So I had to make sure that I completed a command before trying to print the results.

Anyway, I could confirm that I was able to read the manufacturer and chip ID from the FLASH ROM and I could erase a sector and write bytes via the MECB 6809.

There's just one thing really nagging me - I can't seem to work out when the FLASH operation (erase or write) is actually finished. If I read the data sheet correctly it seems like all I need to do is read from the chip and check if bit 6 stops toggling between subsequent reads. But it seemed that this never seemed to be long enough (so when I try to print the results via ASSIST09 it would crash because ASSIST09 wasn't available). At the moment I just have a delay loop that waits the appropriate time after each command and that seems to work. It's nothing critical because I just wanted to check whether the device could be written to via software ... but it is very unsatisfying not knowing what I am doing wrong with the processing status check.

I've tentatively added my bit of test code to GitHub in case it is of interest:
https://github.com/epaell/MECB/tree/main/FLASH_test

epaell wrote: ↑Tue Jul 02, 2024 5:44 am There's just one thing really nagging me - I can't seem to work out when the FLASH operation (erase or write) is actually finished. If I read the data sheet correctly it seems like all I need to do is read from the chip and check if bit 6 stops toggling between subsequent reads. But it seemed that this never seemed to be long enough (so when I try to print the results via ASSIST09 it would crash because ASSIST09 wasn't available). At the moment I just have a delay loop that waits the appropriate time after each command and that seems to work. It's nothing critical because I just wanted to check whether the device could be written to via software ... but it is very unsatisfying not knowing what I am doing wrong with the processing status check.

Awesome work. You seem to be getting to things much faster than me! I had to spend most of my available time today on administrative tasks, like order fullfilment, stock receipt and inventory re-ordering etc.

My reading of the SST datasheet was that I would try the more traditional Data Polling method. As used on the 28C256 etc.
i.e. Reading back the last written byte and comparing it to what is expected. Specifically that the MSB (b7) is inverted.
On an erase operation the b7 bit would be zero (0), until the erase operation (to '1') has been completed.

I did note:

The actual completion of the nonvolatile write is asynchronous with the system; therefore, either a
Data# Polling or Toggle Bit read may be simultaneous with the completion of the Write cycle. If this
occurs, the system may possibly get an erroneous result, i.e., valid data may appear to conflict with
either DQ7 or DQ6. In order to prevent spurious rejection, if an erroneous result occurs, the software
routine should include a loop to read the accessed location an additional two (2) times. If both reads
are valid, then the device has completed the Write cycle, otherwise the rejection is valid.

On this basis, I would consider a data poll read of the last byte written to need to be successful on 3 consecutive reads, for the operation to be considered complete.

epaell wrote: ↑Tue Jul 02, 2024 5:44 am I've tentatively added my bit of test code to GitHub in case it is of interest:
https://github.com/epaell/MECB/tree/main/FLASH_test

Nice. I'll see if I can take a look sometime tomorrow.

BTW, the version in GitHub only has the simple delay version. I left out my polling-based wait functionality just because I couldn't get it to work. I did also add an extra bit to wait for some number of reads where the data didn't change but that didn't seem to help either. Of course, I may have just had some silly error in my coding - perhaps I'll try again when I get a chance again and/or try the bit-7 version. I'm still trying to understand GitHub - something seems to have changed since I last used it and I'm finding it really messy to push things back up to the remote repository (it works via the Desktop App but I prefer just doing it via the command line but that complains about password authentication not working any more). Bah, too much fighting with software for one day

With a fresh day, it occurred to me that the maximum 20µs Byte-Program timing, is actually quite fast!
Especially when you take into consideration writing the whole setup command sequence, and the cycles that would then be required to "data-poll" correctly 3 times sequentially!

With this in mind, there's probably little real speed advantage to data polling (if any!), versus a simple 20µs+ delay.
But, the remaining issue (of course), is the clock speed dependence of a simple delay-loop solution.
On this basis, perhaps polling might still be beneficial. Hmm..

Yes, my feeling is that polling should really be more reliable (clock-speed independent). I'll probably need a few more "fresh days" before I can look into this again.