6502: hardware & software

Oric 1 / Atmos was a nice 6502 based micro. But the most sophisticated I have seen and used was the BBC model B micro, which was really about as good as it gets for an 8-bit micro. It had the best version of BASIC (with support for in-line assembler), the best keyboard, and the most advanced hardware design of any of the 6502 micros, IMHO; it was also pretty much the most expensive, although still cheaper than apple. It is also worth mentioning that the design of the ARM microprocessor (and company of the same name) evolved directly from the team the designed the BBC micro.

en.wikipedia.org

BBC Micro - Wikipedia

en.wikipedia.org en.wikipedia.org

Acorn BBC Microcomputer System

www.oldcomputers.net

1768413480333.png
 
blackbird9 said:
Oric 1 / Atmos was a nice 6502 based micro.
Click to expand...
I don't agree. Oric is awful computer and 6502 is the only good thing there. The graphic mode is very bad. I have experience with cassette tape for storage it this is definitely awful. Only a person who have not seen Apple II and Oric is the only PC around may think it is something good.
 
Fun times with a 6510. You can write to an IO register. Read back from the same address and get contents of ROM, or RAM. And then there was Color RAM that only had nibbles so the upper 4 bits were gibberish.
 
I never had trouble with the oric cassette interface, I had a small Sharp casette player and it always worked fine with the oric . The one that used to give me a lot of trouble with cassettes was the zx spectrum. And the other really bad one was the QL microdrive. As for graphics... oric used serial color attribues, once you learned how it works, it's ok. Of course we cannot compare to amiga, the oric was similar to the zx-spectrum that it competed against. Lots of games were written for oric. The atmos was a very nice build with high quality full-travel keyboard, much better than sinclair. The alps mini-printer was excellent too. So I don't agree, the oric was a nice box for the price, about 1/4 to 1/3 the price of a BBC. Apple II cost about 6 times the price of oric in uk , for most people it was impossible to afford apple, they were not very popular here, especially for home users. People who wanted a more powerful machine usually bought the BBC micro.
1768484214869.png


The main problem for oric, was they were too late to the market. By the time it was launched, Sinclair was already very big with the spectrum, and had a large installed base of software already available. So when oric was launched, as oric-1, the hardware was better built than spectrum, but the amount of software available was much less than for the spectrum. So the spectrum won that battle, because people bought the machine that they could get the most software for, especially games, of course. The price of the oric and spectrum was about the same.
1768484392324.png

A bit later they added a floppy drive, and the mini-printer was good too. It was a nice system, for low cost. Oric was big in France after they ended in UK, and I think some other european countries also. But sinclair and acorn were the two big winners in the uk.
 
Last edited:
blackbird9 said:
I never had trouble with the oric cassette interface, I had a small Sharp casette player and it always worked fine with the oric . The one that used to give me a lot of trouble with cassettes was the zx spectrum. And the other really bad one was the QL microdrive. As for graphics... oric used serial color attribues, once you learned how it works, it's ok. Of course we cannot compare to amiga, the oric was similar to the zx-spectrum that it competed against. Lots of games were written for oric. The atmos was a very nice build with high quality full-travel keyboard, much better than sinclair. The alps mini-printer was excellent too. So I don't agree, the oric was a nice box for the price, about 1/4 to 1/3 the price of a BBC. Apple II cost about 6 times the price of oric in uk , for most people it was impossible to afford apple, they were not very popular here, especially for home users. People who wanted a more powerful machine usually bought the BBC micro.
View attachment 24926

The main problem for oric, was they were too late to the market. By the time it was launched, Sinclair was already very big with the spectrum, and had a large installed base of software already available. So when oric was launched, as oric-1, the hardware was better built than spectrum, but the amount of software available was much less than for the spectrum. So the spectrum won that battle, because people bought the machine that they could get the most software for. The price of oric and spectrum was about the same.
View attachment 24927
A bit later they added a floppy drive, and the mini-printer was good too. It was a nice system, for low cost. Oric was big in France after they ended in UK, and I think some other european countries also. But sinclair and acorn were the two big winners in the uk.
Click to expand...
Back in former Yugoslavia, Oric computers were very widespread.
They featured dedicated coprocessors for graphics and sound.

Of course, as you already mentioned, the Oric appeared later, so it naturally benefited from more advanced design decisions. Unfortunately, it also arrived too late to be seriously recognized, as the market was already heavily saturated with Spectrum software.
 
Isoux said:
while the ZX Spectrum had no graphics coprocessor at all. Instead, the CPU itself was interrupted whenever display data needed to be processed
Click to expand...
this is not true. there where vblank interrupts evey 1/50s and code / data access was somewhat slower for the first 16k because of the collision with the fb scan. the fb scan collision was present in all computers
 
covacat said:
this is not true. there where vblank interrupts evey 1/50s and code / data access was somewhat slower for the first 16k because of the collision with the fb scan. the fb scan collision was present in all computers
Click to expand...
You’re absolutely right. My statement was based on unconfirmed information I had heard, and I should not have presented it as a fact. I withdraw it.
 
This looks pretty cool.
theoasisbbs.com

C64 Ultimate teardown

C64 Ultimate teardown shows ports, FPGA features, SID sockets, turbo mode, and real-world game tests in MVG's review.
theoasisbbs.com theoasisbbs.com

It's an FPGA implementation of a C64. Looks neat! The C64 was another great machine, of course much more advanced than the oric:)
I like the 'basic' one that looks like the original, not the new transparent case one!
 
I mean, the C64 had sprite graphics and the SID... the hardware was a lot more advanced than the oric, which was closer to the spectrum in design and capability. And of course the C64 cost a lot more too!. I can just about remember the uk prices, the speccy and oric were both the same price, about 120 pounds, the C64 was something like 330, and the beeb model b sold for 400, the beeb was about the most expensive 8-bit back then, ignoring the apple II. Those were uk prices of course. And 400 in 1984 money must be at least 1000 now, adjustting for inflation, so to buy a beeb model b was pretty expensive, like buying quite a good PC today. The oric was pretty good for an entry level machine, but of course we can't compare it to a C64 or beeb, you can think of the oric about the same as the zx-spectrum, but better made than the sinclair junk. The oric had AY-3-8910 sound chip, but it didn't have anything as powerful as the C64 SID or the C64 sprite graphics, the oric graphics was pretty primitve, just a frame buffer like the speccy, you had to do everything in software, there was no graphics chip as such in the oric, at least not in the oric-1 and atmos. The oric ULA contained the logic to scan the frame buffer but it was only a basic frame buffer (in dram too, no video ram), there was nothing like sprite graphics.

I think oric brought out later versions of their machines, maybe those had better graphics hardware, but we didn't get those sold in the uk. And then once the amiga (especially) and ST came out, all the 8-bit stuff was pretty much in the bin in hardware terms.
 
kent_dorfman766 said:
Well, stuffing 6500 machine code into strings and executing them was the only way to get any speed out of anything. The BASIC interpreter was just too slow, otherwise. Also allowed for another legacy niche method called self-modifying code.
Click to expand...
I respectfully disagree. And I did a little bit of commercial programming for the Commodore Pet, made many hundreds of "Deutsche Mark" from it (before the Euro was invented).

Compared to the speed of input from a human on the keyboard, and the speed at which the floppy disk operated, the Basic interpreter was not always the bottleneck. For a task like an address book, or a simple accounting application (keeping track of bills coming in and going out), it worked just fine.

Now for gaming and for numerical computation, Basic was pretty hopeless. And the early 6502 CPUs were also not very fast, with a 1 MHz clock and 2-4 CPI. At the same time you could get Z80s with 4 MHz clocks, but they often had higher CPIs, so they were a bit faster.
 
kent_dorfman766 said:
Well, stuffing 6500 machine code into strings and executing them was the only way to get any speed out of anything. The BASIC interpreter was just too slow, otherwise. Also allowed for another legacy niche method called self-modifying code.
Click to expand...
There is BASIC compiler, at least for Apple II.
 
For things like data entry the C64 and its BASIC interpreter worked just fine. I remember writing an application for a friend's dad who had a few too many colleagues who would bet on the outcome of the Tour de France to keep track of on paper. BASIC was fine for doing that. Sure it was sluggish, but text input and the calculations were a lot easier to handle from BASIC.

Nowadays I'm trying to pull visual effects out of the machine that flip the VIC II video chip into different display modes two times per screen refresh (text at the top and bottom, multicolour bitmap in between). That requires catching and handling the raster interrupt at two exact scanlines of the display each frame, and this can only really be done in machine code.

There's also the cc65 C compiler for all sorts of 6502-based machines, and the xa65 cross-assembler for many related CPU types.
 
The BBC micro had one of the fastest basic interpreters, many of the others were licensed from microsoft, but Acorn wrote their own for the beeb. It was written by Sophie Wilson (Roger Wilson at the time) who is now a well-known chip designer, having worked for ARM on instruction set design, amongst others. It was an advanced version of basic with procedures and inline assembly. The BBC reguarly beat other 8-bit micros, inclduing the C64 and apple II, in basic program execution performance tests.

BBC BASIC - Wikipedia

en.wikipedia.org en.wikipedia.org
en.wikipedia.org

Sophie Wilson - Wikipedia

en.wikipedia.org en.wikipedia.org

There is an interesting discussion here of what gave bbc basic better performance compared to other 8-bit micros at the time. Much of the speed advantage came from the hardware used, but there were also some clever optimisations that were used to speed it up in software. Or perhaps you could say never garbage collecting the basic heap was cheating ... 😂 I remember how the oric used to slow right up literally for minutes while it's poor little 1 MHz 6502 would chunter away garbage collecting the basic heap, I used to be able to recognise when it was happening by the characteristic repetitive background noise coming from the speaker. 😁 .
retrocomputing.stackexchange.com

BBC/Acorn BASIC, what made it so fast?

As I look over old versions of BASIC trying to piece together their history, I come across repeated indications that BBC Basic was really fast. One list puts it running the Ahl benchmark (for all its
retrocomputing.stackexchange.com retrocomputing.stackexchange.com
 
the quality of the interpreter was more important than the cpu
the spectrum had a 3.5 MHz Z80 and the amstrad cpc 464 had 4.0 MHz Z80. see difference in benchmarks here

also basic compilers were trash (at least the spectrum ones). i suspect they were not even real compilers. just some interpreters of some intermediate code generated from the original source
compiled basic programs were huge (huge runtime) and slow

on the other hand the hisoft pascal compiler kicked ass. small code and blazing fast code.
 
Started off with Ben Eater's 6502 kit. Added a bunch of other components afterwards. Did the address decoding with a 22V10 for example. Should pick this up again. It was great fun tinkering with it.
 

Attachments

  • 20200630_205755_small.jpg
    20200630_205755_small.jpg
    639.3 KB · Views: 281
covacat said:
the quality of the interpreter was more important than the cpu
the spectrum had a 3.5 MHz Z80 and the amstrad cpc 464 had 4.0 MHz Z80. see difference in benchmarks here

also basic compilers were trash (at least the spectrum ones). i suspect they were not even real compilers. just some interpreters of some intermediate code generated from the original source
compiled basic programs were huge (huge runtime) and slow

on the other hand the hisoft pascal compiler kicked ass. small code and blazing fast code.
Click to expand...
A lot of 'wasted time' contributing to slow execution of code within BASIC interpreters is frequent traversal of line number locations, used in GOTO and GOSUB type commands. Commodore BASIC used within the PET, VIC20 and C64 did not cache line number address locations, meaning a loop calling a subroutine would search for the address of a particular line number every time the subroutine was called.

By creating a 'line number:address' lookup cache table within the interpreter, it is possible to increase the speed of execution easily. The speed increase achievable via this technique is proportional to the usage of subroutines. Subroutines were typically stored within the high line number areas of the BASIC program - typically located towards the end of the program, meaning more line numbers to search, using the line number linked list. If you had a frequently called subroutine at the end of the program, this line number:address cache could speed up program execution by up to 500%, which is a significant amount. The cost of this cache was only a few bytes per called subroutine making it a good tradeoff.
 
You must log in or register to reply here.
Back
Top