Happy New Year and happy hacking in 2016!

[satpro]

BigDumbDinosaur wrote:

Hmmm...sounds familiar.

Quote:

Reasonable graphics, any disk system, standard 65x-compatible I/O, and that it should be open to all as in open source, free, and for the benefit of all.

RE: the disk system, I've periodically gone into fits of research trying to learn enough about SATA to see if it's viable with the 65C816. To date, I have been unable to find anything in the way of a SATA controller that is the analog of the 53CF94 SCSI controller I use with POC. The protocol is, I think, too complicated to bit-bang, so some sort of ASIC seems to be mandatory.

If SATA can be implemented then the door has been opened to inexpensive, high capacity mass storage via readily available commodity disks.

I kind of/sort of understand that stuff (SATA) in x86 as it is implemented for PC systems, but I've always been involved trying to implement it at the c64 level, and that was too involved. For me it really became just a dead end. My interest was in straight x86 boot code assembly and converting that to 65x.

This is different and I know I can help because I have studied lots about it while trying to get my Winc64 self-booting for a PC. If ASIC is necessary with the '816 then we put ASIC on the board and interface the '816 to it. SATA is just a system and, while not exactly 65x, it has a protocol and we can't want to push the cpu and then leave it hanging -- success often has strange bedfellows. It's not like the '816 can't be "part" of a larger, more involved system. Heck, that's what killed it in the first place -- no one really pushed (or exploited) it.

BTW, there is a product called IDE64 that works as a cartridge on the c64 (6510) and it functions as a very capable hard drive/CD controller. So it can be done.

BDD: keep reading. Your knowledge will really come in handy in 2016. In the meantime I'll dig up my SATA stuff.

Re: Garth --> See? This is how we start. Small steps at first. But I do think you're right about the SD cards.

[BigDumbDinosaur]

satpro wrote:

I kind of/sort of understand that stuff (SATA) in x86 as it is implemented for PC systems, but I've always been involved trying to implement it at the c64 level, and that was too involved. For me it really became just a dead end.

This is different and I know I can help because I have studied lots about it while trying to get my Winc64 self-booting for a PC. If ASIC is necessary with the '816 then we put ASIC on the board and interface the '816 to it. SATA is just a system and, while not exactly 65x, it has a protocol and we can't want to push the cpu and then leave it hanging -- success often has strange bedfellows. It's not like the '816 can't be "part" of a larger, more involved system. Heck, that's what killed it in the first place -- no one really pushed (or exploited) it.

If it hadn't been for the availability of the 53CF94 I would not have entertained the idea of equipping POC with a SCSI port. André Fachat implemented SCSI on his homebrew system via bit-banging, but that wasn't a route I was willing to take. I was familiar with the old NCR 53C90A SCSI controller, so I figured that it or its descendants would be the logical approach to take.

Quote:

BTW, there is a product called IDE64 that works as a cartridge on the c64 (6510) and it functions as a very capable hard drive/CD controller. So it can be done.

I have some very limited knowledge of IDE64, but was not at all interested in using IDE hardware.

Quote:

BDD: keep reading. Your knowledge will really come in handy in 2016. In the meantime I'll dig up my SATA stuff.

Right now, SATA is low on the list of things to explore. I gave it some thought four to five years ago before deciding to go with SCSI. The lack of a 65xx bus-compatible controller caused me to set the idea aside.

[mkl0815]

Today i soldered the 4x8 keyboard to the cable and the plug on the other side. It worked and I was able to proof, that the keyboard works well after 28 years.
But the voltage regulator get fairly hot during longer operation and suddenly my TV set died during my tests. Even with nothing attached I can switch it on (after a few minutes powerless) and it switches itself off after a few seconds.
There's a trick to pull off the BAS signal from a solder-bridge from the board itself to drive a video input of a normal monitor. I will try this maybe tomorrow.

My plans are like 28 years ago. Build a working computer out that thing. First I ordered an old electronic typewriter for 23 Euro, because the keyboard is a compatible 8x8 matrix keyboard for this puppy. The typewriter has also a V.24 interface, so I can use it as a printer. Additionally I found an old tape recorder that should work with the tape interface of the computer. All parts were available at the time I wanted to have this kit. That's important for me. At the and it should be the computer I never had.
In general it was easy to buy the things you really need for your life in the GDR, but things that make life more comfortable were difficult to get like a car (waiting about 10 years if you ordered one). If a child was born two important things were done (beside giving a name and so on ...). First a bank account was created were money from birthday presents and similar events were stored and a car (the famous Trabant) was ordered. If the child turned 18 years old it had probably enough money to buy the car that was ready for delivery

The biggest problem is that the pcb-connectors are not longer available. So I'll try the get some old one and build adapter boards to use more common ones. So I can rebuild the old extensions with new parts.

[sark02]

magetoo wrote:

Myself, I'm hoping to get started on my from-scratch build; getting an 8-bit system up and running, bootstrapping everything from nothing without "cheating" by using something that's already there (like cross-assemblers, microcontrollers or FPGAs). It's a challenge that ought to be interesting!

That's quite a challenge - good luck! How manual are you going? I looked at a system a (very) long time ago that had discrete switches for address/data and control lines, which enabled individual bus cycles to be entered by the operator. The idea was to manually load opcodes into RAM and then have the processor execute them (from its reset vector). It took about four hours of toggling switches before I realized that this level of manual labor was not for me.

The next level would be to build a hardware-driven keypad/7-segment display interface which lets you enter address/data in hex - way better than toggle switches. This would be similar to a KIM-1 (only still all-hardware as opposed to ROM code).

Then you'd need to enter enough hex codes to enable a serial loader. But if you're not going to use a cross-assembler from that point on (to create code that you can download to your target), then it's not immediately clear what comes next.

Realize that the people who built the 8-bit computers of the 70s and 80s used cross-assemblers on mainframes and minicomputers... so I don't think it's cheating to follow a similar flow... if you're looking to answer the question, "What could I have done back then?"

Good luck! Keep us all updated!

[Arlet]

Quote:

I looked at a system a (very) long time ago that had discrete switches for address/data and control lines, which enabled individual bus cycles to be entered by the operator. The idea was to manually load opcodes into RAM and then have the processor execute them (from its reset vector). It took about four hours of toggling switches before I realized that this level of manual labor was not for me.

Instead of toggle switches you could make a row of photodiodes, and then pull a strip of paper underneath with white/black squares.

[GARTHWILSON]

Related, see the manual program entry on a PDP-8: https://www.youtube.com/watch?v=DPioENtAHuY

[BigEd]

There's a playlist for toggling front panels!
https://www.youtube.com/watch?v=iIsZVqh ... mc7tm9ZTnF

[Aslak3]

BigEd wrote:

There's a playlist for toggling front panels!
https://www.youtube.com/watch?v=iIsZVqh ... mc7tm9ZTnF

I rather like the four parts starting from here - https://www.youtube.com/watch?v=XV-7J5y1TQc - I learned a few things about how the programming cycle was done on these old machines, I guess they were minicomputers? And the music is classic 70s, which I love.

My plans for the year are to implement the HDL for the functionality I'd like to add to my MAXI09 computer, which is, after working on it for the best part of 10 months, now a physical thing. A DMA controller, MMU (memory pager, really), SPI controller (though I may borrow an existing one), and other odds and ends. Then it will be on to implementing some kind of operating system for the machine, and finally some games. I have a few ideas there, but it's going to push me, just like the HDL. I'm also going to try writing in my blog more often, though this is also a challenge.

Should all be fun, which is the most important thing!

[sark02]

GARTHWILSON wrote:

Related, see the manual program entry on a PDP-8: https://www.youtube.com/watch?v=DPioENtAHuY

Great example, thanks. My personal favorite method of manual program entry is the way the Apollo Guidance Computer programs were hand-woven into core rope memory; as shown here:

https://www.youtube.com/watch?v=P12r8DKHsak

[magetoo]

sark02 wrote:

magetoo wrote:

Myself, I'm hoping to get started on my from-scratch build; getting an 8-bit system up and running, bootstrapping everything from nothing without "cheating" by using something that's already there (like cross-assemblers, microcontrollers or FPGAs). It's a challenge that ought to be interesting!

That's quite a challenge - good luck! How manual are you going?

I suppose I'd have to say "reasonably" manual, whatever that means.

Toggle switches for each individual line seem a little bit too much. A small diode "boot ROM" might be an option if I can get a useful amount of code into something I'd be willing to solder, hexadecimal entry into an SRAM before setting the CPU loose makes sense too; even flipping individual bits might be acceptable if one can use an EPROM and have it be persistent.

It comes down to a tradeoff between parts count, hardware complexity and convenience for entering the program.

Quote:

Realize that the people who built the 8-bit computers of the 70s and 80s used cross-assemblers on mainframes and minicomputers... so I don't think it's cheating to follow a similar flow... if you're looking to answer the question, "What could I have done back then?"

That's a good point. (A finished program in binary form won't do any good if there's no way to get it into RAM, though!) I'd like to get at the point where I have something that turns on and runs simple programs at least - at that point a loader program might be the logical next step.

Quote:

Good luck! Keep us all updated!

Thanks!

Arlet wrote:

Instead of toggle switches you could make a row of photodiodes, and then pull a strip of paper underneath with white/black squares.

That's not a crazy idea. I've thought you could maybe use graph paper and then just color in the individual bits. Or use just one or two photodiodes, and a shift register. Then you have somthing that is entirely serial, and could substitute the "paper tape" with anything that can generate a serial bit stream.

[sark02]

magetoo wrote:

A small diode "boot ROM" might be an option if I can get a useful amount of code into something I'd be willing to solder, hexadecimal entry into an SRAM before setting the CPU loose makes sense too; even flipping individual bits might be acceptable if one can use an EPROM and have it be persistent.

EEPROM would be 70s-era tech. Unless you have a UV eraser, I would suggest a FLASH chip, maybe something like this: http://www.digikey.com/product-detail/e ... ND/2297826, datasheet: http://ww1.microchip.com/downloads/en/D ... 25022B.pdf. If the CPU keeps the bus floating when in reset, then with appropriate manual signals, you should be able to perform programming cycles to the flash, and then release reset and off it goes. All without having to remove devices.

Arlet wrote:

Instead of toggle switches you could make a row of photodiodes, and then pull a strip of paper underneath with white/black squares.

A polled serial loader through the UART is, I would think, the simplest, as you have the UART timing and framing taken care of. I'm not certain Arlet was serious, but if he was then a GPIO photodiode (parallel or serial) with paper tape would earn you a ton of nerd cred, but I suspect it would be way more bytes to implement reliably as it becomes something like a bar-code reader and you'd need sync bits to establish the timing, for example.

It's not uncommon for computers to have "service processors" - CPUs used either to bootstrap or otherwise manage elements of the larger computer distinctly from the main CPU (not a co-processor, rather a completely separate entity). Modern x86 systems have these, and they're often ARM-based BMCs (Baseboard Management Controllers) that do things like run system fans, and perform serial-over-LAN connectivity to the system's UARTs. Older minicomputers might had service processors to sequence and startup the main computer... after which they go idle.

I bring this up to suggest a similar option for a 6502 system: A small Microchip PIC12 or PIC16, or similar AVR could be used as a service processor to bootstrap a ROM-less system from an SD card. The microcontroller would:

• Assert reset to the 6502
  Read data from an SD card (e.g. formatted as Motorola S-Records) and write that data to RAM.
  At end-of-file, release CPU reset

With a single 64KB RAM chip you could set up the address decoding such that the 6502 could only read from the "ROM" area, whilst the PIC could override that gate via its own signal. This gives you effectively a ROM until power is removed.

The scheme then lets you iterate over boot code by removing the SD card. Another fun aspect to this is that it would involve the service processor, and get you into a little PIC or AVR programming - if you like that sort of thing. It's not how a typical 6502 system of the era would be built, but a service processor isn't historically inaccurate.

[Arlet]

sark02 wrote:

I'm not certain Arlet was serious, but if he was then a GPIO photodiode (parallel or serial) with paper tape would earn you a ton of nerd cred, but I suspect it would be way more bytes to implement reliably as it becomes something like a bar-code reader and you'd need sync bits to establish the timing, for example.

I was thinking about something like 8 bits for data, and a sync bit that does the write and increments the address. You'd need an address counter, plus a switch to keep the CPU from the bus. That way it doesn't matter what speed you use.

[GARTHWILSON]

Arlet posted while I was writing, but I'l add this to expand.

sark02 wrote:

Arlet wrote:

Instead of toggle switches you could make a row of photodiodes, and then pull a strip of paper underneath with white/black squares.

A polled serial loader through the UART is, I would think, the simplest, as you have the UART timing and framing taken care of.  I'm not certain Arlet was serious, but if he was then a GPIO photodiode (parallel or serial) with paper tape would earn you a ton of nerd cred, but I suspect it would be way more bytes to implement reliably as it becomes something like a bar-code reader and you'd need sync bits to establish the timing, for example.

Making a manual bar-code wand could get around the need for timing if you go for a pair of photodiodes and run it over a pair of rows of black & white squares, if you make one to be for the clock and one for data, and have them go to a 74HC595 shift register.  The pushbutton on the wand which you press at the beginning of each line would clear the shift register.  The address counter gets initialized upon power-up.  Each 8-bit byte on the paper is preceded by a '1' bit which, when shifted all the way through the shift register with 9 clock pulses, tells the logic to write the shift register's parallel output to the next RAM location and increment the address counter.  This video shows a bar-code wand in use.  I'l try to find one of using such a wand to enter a program and come back and edit this.

[Edit:]  No videos, but here's a picture of a program to enter by bar code on the HP-41 calculator, added almost simultaneously with Mike's below:

(Regarding the nine program registers it says it needs, those are seven bytes each, so 63 bytes.)

Before the internet existed, user groups had magazines and newsletters, plus meetings where they actually got together (gasp!).  A nice thing about bar code was that you could distribute programs with nothing more than a photocopier, and it was much faster for the recipients to scan the bar code than to manually enter the program.

Now again envision having pairs of rows of squares to run your home-made barcode wand over to enter a bootstrap loader program with no ROM, the top row for clock and the bottom for data, perhaps done manually on quadrille paper, with each bit made much wider than what you see above.  Since it's synchronous serial, it would not matter how fast or slow you run the wand over each line, or whether you keep a consistent speed or not.  You should comfortably get about 50 bytes per 8½x11" page, in landscape orientation, ten lines of five bytes each.

[barrym95838]

Snipped from the April 1980 issue of Byte (the first one I received by mail as a subscription):

Many Byte .pdfs are available in this thread:

http://atariage.com/forums/topic/167235-byte-magazine/

Mike B.

[magetoo]

sark02, I'm not sure you were adressing me specifically (I'm guessing not all of the time), but I'll comment on this as it relates to the project I'm planning, in case anyone is interested. And I hope I don't come off as too cranky.

sark02 wrote:

magetoo wrote:

A small diode "boot ROM" might be an option if I can get a useful amount of code into something I'd be willing to solder, hexadecimal entry into an SRAM before setting the CPU loose makes sense too; even flipping individual bits might be acceptable if one can use an EPROM and have it be persistent.

EEPROM would be 70s-era tech. Unless you have a UV eraser, I would suggest a FLASH chip, maybe something like this:

Yes, we certainly wouldn't want any 1970s tech in our 6502-based systems! :-)

That seems like an interesting chip, thanks! I might use that when I get to a larger system.

However, keep in mind that within the bounds of this project, I have a soldering iron, the usual parts in a hobbyist electronics lab, and no computer. The conveniences that Flash memory provides, like in-system single-supply-voltage programming, aren't really all that relevant at that point.

Quote:

A polled serial loader through the UART is, I would think, the simplest, as you have the UART timing and framing taken care of.

It seems that would imply that there would be a UART on the other end. I know that there used to be "bare" UARTs that would just read a data word from a parallel bus and shove it out serially, but I don't think those are made any more. Which means that there would have to be another processor on the other end, driving another UART - and I'm back to where I started, having to bootstrap that system.

A simple shift register seems more straightforward to me. Data, clock, perhaps a word strobe signal - that seems simple enough to generate with a combination of analog and digital circuitry.

A UART would also require initialization code, so it couldn't be an option for initial bootstrapping, whereas the parallel output of a simple shift register could be used to feed data words to an SRAM, or maybe even feed instructions to a CPU directly, if you could also reliably generate a clock from the serial data stream. (I'm not saying that's necessarily a good option, but it's something I've thought of.)

Quote:

It's not uncommon for computers to have "service processors"

I just want to acknowledge that this is also a pretty nifty way to structure one's system, even if it's not directly relevant here.