als je toch op gaatjesboard hebt gebouwd kan je ook grotere EPROMs gebruiken.

Tjerk

Dat gaat hem niet worden. Het is destijds zeer compact gebouwd en ik wil de bedrading niet wijzigen. Kan momenteel geen foto maken.

Ik denk dat software helemaal jouw ding is, net als bij Paul van Oers, die ik in de emails genoemd heb. Reeds lang voor de correctie in RB heeft die het foutje wat in de software zat opgelost.

Sofware is hedentendage niet ECHT mijn ding. Waar ik in geïnteresseerd ben is oude hardware met de oerprocessors als MCS-48, MCS-51 en 6502 achtigen, die specifieke hardware rechtstreeks aansturen. Het is vaak onvoorstelbaar wat ze allemaal in 1K-, 2K- of 4K-byte gepropt kregen.
De tegenwoordige mentaliteit dat alles op een besturingssysteem moet draaien met onevenredig veel RAM en opslagcapaciteit voor de toepassing interesseert mij niet zo erg, dat leidt tot software waarvan de maker geen idee heeft hoe de hardware werkt en dus tot fouten (die dan weer in telkens nieuwe versies worden opgelost en nieuwe problemen worden geïntroduceerd). Als het programma zo groot geworden is dat het niet meer fysiek past dan stopt de fabrikant van de hardware met ondersteunen. Vroeger MOEST het gewoon in één keer goed zijn.
Het mooiste voorbeeld van heel universeel gebleken hardware vind ik nog steeds de Atari 2600 spelcomputer. Geen software intern, alles zit in de cardridge, en de eerste cardridges waren slechts 2K- en 4Kbyte. Er is een schaakprogramma in 4K, inclusief de videoweergave. Misschien geen heel geweldig sterk schaakprogramma, maar laat iemand het NU maar eens proberen te maken.
Ik heb meetapparatuur voorbij zien komen die op windows (ce?) draaide. Opstarten duurde relatief lang en na een paar jaar al geen ondersteuning meer.
Ben bezig geweest met Raspberry Pi, maar de typen volgen elkaar te snel op, moeten tegenwoordig als volwaardige PC kunnen draaien en bijna niemand kan er nog timing critische dingen mee doen. Een "snelle" processor die door wachtlussen echt niet zo snel meer is.
Arduino's programmeer je iets dichter op de hardware, maar zelfs de C++ achtige software met kant en klare libraries maakt dat je bij wat complexere projecten NIET meer weet welke library welke hardware in de processor gebruikt. En dan maar zoeken, waarom loopt die interne timer die ik rechtstreeks programmeer vanuit mijn hoofdprogramma niet of onbetrouwbaar? Simpel omdat een van de libraries hem al geclaimt heeft waarschijnlijk?!?

In een assembly programma heb je de volledige verantwoordelijkheid dat alles goed loopt en met de juiste timing.
In een auto ga je geen vliegtuigmotor zetten met een enorme vertragingskast erop. Maar zo lijkt het WEL met de huidige computers, windows stelt belachelijke eisen aan een PC en als de computer net niet krachtig genoeg is dan heet het dat de computer ongeschikt is voor die windows versie. Maar het is andersom, windows stelt te hoge eisen aan de hardware. En dat bijna allemaal omdat de overhead van verschillende lagen software veel te groot is.
Goed programmeren van embedded software is een vak, en ik wil ZEKER niet pretenderen dat ik er veel verstand van heb. Maar hoe universeler een systeem moet zijn, hoe ingewikkelder en onoverzichtelijker de software wordt EN de overhead voor de hardware.

Embedded software voor kleine apparaten vind ik interessant, als de programmeur moeite heeft moeten doen om met de beperkte hardware en de beperkte programmaruimte creatief heeft moeten zijn om toch iets moois en betrouwbaars te maken!