Marlagram

... Atari programming requires racing the beam, updating graphics registers just before the instant they’ll be used to paint the next pixels on the current scan line. With only 76 CPU cycles per scan line, there just isn’t enough time for the poor 6502 to do very much. Want to update the foreground color multiple times at different horizontal positions? OK, but there might not be enough time remaining to also update the pixel bitmap during the scan line, or set the sprite positions. It’s a series of difficult tradeoffs and code optimization puzzles.
...
Activision’s Pitfall was one of the most popular games for the Atari 2600. For the sequel Pitfall II, expectations were high, and the game’s designer David Crane did something that had never been done before: put a full-blown coprocessor inside the game cartridge. Crane’s DPC (Display Processor Chip) added two additional hardware sound channels, a music sequencing capability, a hardware random number generator, and a graphics streaming capability with built-in options for masking, reversing, or swizzling the bits.
...
The DPC provides some extensions to speed up this process. From my study of the chip, it works like this:

Writing to a special pair of addresses in the cartridge’s address space will set up a graphics stream pointer
Reading from a special address will return the next byte from the stream pointer, and increment the pointer
...
This reduces the total number of CPU cycles for every repetition from 10 down to 7, enabling the pixel bitmap to be updated every 21 pixels instead of only every 30 pixels – quite a nice improvement.
...

... As an example of a large product for an 8-bit machine, I worked on the BitStik CAD software for Apple II and BBC Micro systems from 1984 to 1986. That used Apple II machines with Z80 CP/M cards for coding (with WordStar) and assembling and linking (with Microsoft's M80 assembler, using its .6502 directive). We had a very simple networked hard disk system for source code, which used ribbon cables to connect machines to the disk cabinet.

Executables would be written onto bootable Apple DOS disks, and then you'd reboot into Apple DOS and try out your changes. This meant we were using the same machines for coding and testing, but frequently switching between OSes on them.

We had machines with hardware debugger cards (can't remember the name) for difficult problems. It worked pretty well, all things considered.

Since WordStar has attracted attention, this was "Classic" WordStar 3.3 IIRC. It has a "Non-Document" mode where it works as a plain text editor, and if you turned off the menus and delays, it was decently fast on a 3.58MHz Z80. Its "Column Mode", which lets you define and operate on a rectangular block of text that doesn't have to contain complete lines, was pretty useful when writing assembler code.

Source control was entirely manual. There was a big wallchart for developers to claim control of source files. They had the copies they were working on in their personal areas of the hard disk, and would put their changed versions back into the shared area and cross out their initials on the chart. Backups were taken weekly, and before any major changes. More copies than that would have been hard work: the hard disk was only 20MB for five developers.

This did give each developer enough hard disk space for a full set of object files, so linking from hard disk to hard disk was possible. That was a lot faster than doing it with floppies. The linker script was fairly complicated, because the Apple II's memory map is quite fragmented. We were using all the space we could get, plus overlays in the multiple "language cards" that were provided by 128KB expansion cards. The Apple //e memory map was less easy to exploit, and the //c seemed like an exercise in perverted ingenuity to me. We'd mostly moved onto programming with C on MS-DOS by then.

There were a lot of floppy disks around, and we had to be disciplined with them. After one new developer was a problem with that, the rule became that any unlabelled disk was subject to summary destruction, by anyone who felt like it.

... In the way of introduction, I was the PDP-8 Software Development manager in the late 1960's during the time when PS/8, later called OS/8, was created. I started working for DEC in the summer of 1967. At that time, Roger Pyle was the PDP-8 Software Development supervisor. Roger, another person whose name was John, and one or two others whose names elude me right now, and I, developed the 4K Disk Monitor system and its associated software. At some point, Roger moved on to another project, and I became the PDP-8 Software Development manager (or supervisor, not sure which.) I moved into PDP-8 Marketing (I think it was in 1970) and then Dennis (Denny) Pavlock became the PDP-8 Software Development manager for several more years. This was a challenging and interesting period; and the development of PDP-8 software remains, in my opinion, unique in the history of computing.

The reason for its uniqueness is that all of Digital's PDP-8 system software was developed by an unusually small group of creative, highly motivated and productive people in an environment where there were no standards and very few rules. It was also unique because, as I'm sure you know, PDP-8 code had to be constructed out of subroutines that consisted of no more than 128 12-bit words, and programs had to be able to fit in 4K words of memory, so code had to be extremely compact.

Prior to about 1969, almost all DEC software development for the PDP-8 family of computers was done using a cross assembler. Initially that was done on a PDP-6 computer, and I think the cross-assembler was called PAL6. Some programmers would write their programs on coding sheets, give those pages to the "Tape Prep" group, which consisted of a group of typists who would type the code, typically on a PDP-5 computer with an ASR-33 Teletype using the editor. The Tape Prep person, when finished, would output the program on the "high-speed" paper tape punch and then return the coding sheets and tape to the programmer. The programmer would then load that tape into the PDP-6, run PAL6, copy the binary file to the high speed paper tape punch, and save the program source on a DECtape. We would then load the binary paper tape on one of the development PDP-8 computers and try to run the program.

Of course it was likely that the program would have assembly errors, so the programmer would edit the code using TECO, and try again, from time to time saving the latest version on DECtape. The PDP-6 was not very reliable then, maybe on a good day only "crashing" a few times. So moans and groans would periodically be heard coming from the PDP-6 computer room each time the system crashed, as programmers thought about how much editing they would have to do over again. Also in those days, disk storage was extremely limited. The PDP-6 that we used in the Maynard mill had a drum memory with a capacity that would have looked small on a PC in the early 1980's. So DECtapes would constantly be spinning on the front of the PDP-6 as programmers copied their code to or from the tapes. The PDP-6, by the way, was DEC's 36 bit computer and was roughly equivalent to a mainframe that supported time-sharing.

Once PS/8 became useable, assembly language software development on the PDP-8 became common. Prior to the development of PAL8, the symbol table in PAL III was too limited to assemble anything other than small and medium size programs. The MACRO-8 symbol table was even smaller. PAL8, however, was derived from the MACRO-8 paper tape assembler (maybe a descendent of MACRO-8.) The macro features were removed, and the symbol table was moved to extended memory, vastly expanding its size. But PAL8 was still very slow until someone, I think Richie Lary, implemented a binary search on the PAL8 symbol table. That remains, in my mind, a defining moment, where the PDP-8 became a useful computer rather than an interesting toy. Subsequently, OS/8 and all associated system software and DEC PDP-8 programming languages could be developed entirely on the PDP-8 using OS/8 and the PAL8 assembler.
...

... For the 8085, the Intel architects took the bus interface in another direction. They integrated several components from the support chips for the 8080 into the silicon die, and produced new features which made the 8085 much more useful as a micro-controller than the Z80. For the bus, the major change was to multiplex the data lines with the low address lines. This step allowed them to reuse the 8 saved lines on the 40-pin DIP for other purposes.

Multiplexing the address and data lines meant that they had to add an external address latch, to capture the lower address values, before either writing data or reading data from the bus. The normal read and write lines are present and they behave in a similar manner to the Z80.
...
In a significantly different solution to the Z80, the 8085 uses only one line to differentiate Input/Output and Memory addresses. Using the sense of the line high or low to indicate whether the I/O address space or the memory address space is being addressed. The timing on this IO/M line is also substantially different to the Z80, where here it is valid for the entire cycle of an instruction. It does not become valid when the bus address is valid, rather it is valid from the start of the instruction through to the completion of the instruction.
...
There are textbook “decoder” circuits available to produce the four system signals /IOR /IOW, /MEMR and /MEMW from the 8085 IO/M signal and /RD, /WR, but there is no standard solution for using the 8085 on the Z80 bus.
...

A review of Econet — comparing the cost vs disc systems, showing the installation in a BBC Model B and BBC Master, building a network and a demo of the Level 1 and Level 3 file servers. Also shows the PiEconetBridge v1 and v2 boards and software running.

Short presentation: my simple ASIC concept design of a 3D-like "ray caster" video game hardware accelerator chip, FPGA-tested, then synthesised/submitted to TT04 (Tiny Tapeout 04) for VLSI/ASIC manufacture. Created with OpenLane and the sky130 process (Google/Skywater 130nm Open PDK).

The history of the first microprocessor is murky and ill-defined. For years, the Intel 4004 was generally accepted to hold the title. However, in 1998, the historical record was rewritten as the existence of an earlier system was revealed to the world.

In this video, we'll learn about the MP944, and why many now consider it the first microprocessor. Regardless of whether it was or not, it was extremely complex for its day.

Чисто для истории. Распаковал свою БК и решил выложить недоделанную (к сожалению) версию Элиты для БК. Работал в школе на Чукотке и писали с ребятами на ассемблере. На КУВТ после заставки игра загружалась, а в Андос что-то не хочет, приходится вручную запускать. Проблема была в том, что после 10 класса ребята уехали поступать на материк, а следующие уже захотели делать XCOM. Версия отладочная, надо вспоминать, где лежит скорость корабля, он летал как положено, а тут просто на месте стоит. Ну и выстрелы и взрыв не подключены. Расчёты все реальные, рисуется в буфер на 5000 байт, массив вершин корабля множится на матрицы преобразования, отсечения линий вычисляются, видимость граней. Но доделать уже маловероятно, лет 25 уже прошло. Это на БК-0010.

At last! :D
After casually keeping an eye out since 2004* I finally came across a System/32! At this point it's more of a collectors piece (and a big one at that) but this finally fits into the slot that I left open for a 70's era IBM system that is both small and still somehow functional in a residential environment.

Take an Atari ST, 4 budget synths from 1988, and spend months seeing how far they can go - all while staring at a black-and-white CRT! I took me over a year to make this given most of the equipment was DOA and keeping in mind there's another part coming later this year.

Massive thanks to mu:zines and archive.org for their incredible collections. This led me to all the cheapest gear that people were actually using back in the day. Thanks also to all those I reached out to who verified most of the findings and gave me amazing insights to the gear of the day.

Gear used: Atari 520ST (mostly), Roland MT-100, Yamaha MusicStation PSS-580, Kawai K1, Yamaha EMT-10, Dr T MIDI Recording Studio, Cubase 1.5 and Rotel mini system.

You might think OS/2 is long gone, but it still lingers around in more places then you'd expect. Today's video covers ArcaOS, an OS/2-based operating system designed to work with newer hardware!

ArcaOS: https://www.arcanoae.com/arcaos/

...Origin of the Lexitron Videotype word processing computer. A unique tribute to the historic Lexitron Videotype Word Processing computer, from its conception in 1969 to its production in 1972, and its successful growth and eventual purchase by Raytheon Company. Models: Lexitron 911, Lexitron VT 1202, Lexitron VT 1303. (Run Time: 10 mins, with 3 min Photo Gallery)
...