CP/M auf ATmega88

[Leo C. (rapid)]

Joe G. schrieb:
> Deshalb brauche ich eine Platine, solche Lötarbeiten werden mit
> zunehmenden Alter unmöglich.

Da sind wir Kurzsichtigen wohl im Vorteil. Im Nahbereich gehts bei mir 
immer noch ganz gut.

> Von mir aus reicht die RAM-Disk in der 8-Bit
> Variante.

Ich habe sie jetzt trotzdem mal in die alte 4-Bit Variante eingebaut. 
Ist im SVN zu finden, und braucht das neue BIOS, wie oben geschrieben.

Ich hoffe, das damit ein paar mehr Leute testen können. Ich brauche 
etwas Feedback in Sachen Benutzbarkeit. Außerdem sind wahrscheinlich 
noch Fehler drin, die ich alleine nicht finde.

> @alle
> Gibt es denn außer bein Leo C. Peter und mir noch weitere lauffähige
> Systeme? Wenn nicht, können wir irgendwie helfen?

Das würde mich auch mal interessieren. Insbesondere interessiert mich, 
warum jemand das Ding hier aufbaut, und was er/sie damit tun möchte. 
Grundsätzlich wurde das zwar am Anfang des Threads ausgiebig diskutiert, 
aber was die Leute antreibt, die jetzt tatsächlich bauen, kann ich mir 
gar nicht so richtig vorstellen. ;)

[Peter S. (petersieg)]

Leo C. schrieb:
> Ich habe sie jetzt trotzdem mal in die alte 4-Bit Variante eingebaut.
> Ist im SVN zu finden, und braucht das neue BIOS, wie oben geschrieben.

Habe jetzt mal eine Platine damit ausgestattet..

I>a:stat

A: R/W, Space: 42k
B: R/W, Space: 163k
C: R/W, Space: 129k
I: R/W, Space: 55k

läuft ersteinmal soweit gut..
aber das sieht komisch aus:

I>a:pip ed.com=c:ed.com

I>dir

I: ED       COM
I>ed

Bdos Err On M: Select
I>

Nur mal zu den Gründen, die mich antreiben:
* CP/M ist DAS Ur-Betriebssystem.
* Das mit den heutigen Mikrocontrollern verbandelt ist ansich schon 
interessant
* Man ist automatisch gleichzeitig 'Retro' und modern ;-)
* Man hat eine 'arbeitsfähige' retro-Umgebung mit 2 Chips+SD Karte
* MBasic, C Compiler, Wordstar, dbase-II, etc. etc.
* Aber evtl. kann man Retro+Modern noch weiter verheiraten:
->z.B ADC über AVR nach CP/M verfügbar machen, Frequenzzähler, I2C 
Bausteine

Peter

[Leo C. (rapid)]

Peter Sieg schrieb:
> I>a:pip ed.com=c:ed.com
> Bdos Err On M: Select
> I>

Danke dafür.
Ich hatte heute schon mal was ähnliches, konnte es aber nicht 
reproduzieren. Bei mir war nur der Select auf J, also (genau) eins 
größer als ein existierendes Laufwerk. Jetzt kann ich davon ausgehen, 
daß der Buchstabe Zufall war, der eigentliche Fehler aber nicht.

Gerade nochmal propiert: Fehler versteckt sich. :-(


> Nur mal zu den Gründen, die mich antreiben:
> * CP/M ist DAS Ur-Betriebssystem.

Ich bin sozusagen damit groß geworden. ;-)
Vor allem aber ist mein erster Selbstbaucomputer damit groß geworden.

> * Das mit den heutigen Mikrocontrollern verbandelt ist ansich schon
> interessant
> * Man ist automatisch gleichzeitig 'Retro' und modern ;-)

Genau. Besonders beim Programmieren empfinde ich das so.

> * Man hat eine 'arbeitsfähige' retro-Umgebung mit 2 Chips+SD Karte
> * MBasic, C Compiler, Wordstar, dbase-II, etc. etc.

Es sind jetzt schon 3 Chips. ;) Und beim "arbeitsfähig" bin ich immer 
noch ein wenig skeptisch, wg. (fehlender) Geschwindigkeit. Aber 
prinzipiell ja.

> * Aber evtl. kann man Retro+Modern noch weiter verheiraten:
> ->z.B ADC über AVR nach CP/M verfügbar machen, Frequenzzähler, I2C
> Bausteine

Dafür fehlt mir jetzt der Sinn. Geräte mit ADC, Frequenzzähler, etc, 
programmiert man besser mit was anderem, als ausgerechnet CP/M. Außerdem 
sollte man dann endgültig einen größeren AVR nehmen...

[Joe G. (feinmechaniker)]

So, es ist soweit...
Die Schaltung und das Layout der neuen Platine - sagen wir Version 2.0 
;-)

- das Board ist etwas breiter, so das die VGA direkt angeschlossen 
werden kann.
- auf den freien Pins der VGA liegen zusätzlich die 25 MHz, und SDA/SCL 
zur Erweiterung für I2C

Bitte Änderungen, Vorschläge, Kritik...

Joe

[Peter S. (petersieg)]

@Joe. Den Quarzosi 3,3V von reichelt gibt es nur in SMD.. die DIL's sind 
alle für 5V..? Soll dann die VGA+PS/2 Mimik nicht mit auf die Platine..?
(wobei das auch ok wäre.. und später macht man das zur MicroVGA 
kompatibel von den Anschlüssen her gesehen).

Ich frage mich nur, wie viele sich für weitere Platinen interessieren..?
Bisher hat sich noch kein weiterer 'Nachbauer' geoutet.. ;-)

Peter

[Joe G. (feinmechaniker)]

@Peter
Den Quarzoszillator als SMD hatte ich verworfen. Damit ist der schnelle 
Austausch nicht mehr möglich. Die Variante im DIL Gehäuse kann sehr gut 
auf eine IC Fassung gesteckt werden. Mögliche Quarzoszillatoren bei 
Rei****t z.B. unter Artikel-Nr.: OSZI 25,000000. Meine Testvarianten 
laufen auch sauber mit 3.3V. Damit kann also nun die ganze Schaltung 
wahlweise mit 5V oder 3.3V betrieben werden, wobei die MMC natürlich nur 
mit 3.3V betrieben wird. Versehentliches "falschjumpern" nicht mehr 
möglich. Die Test-VGA hat die gleiche Anschlussbelegung wie die 
MicroVGA, kommt also von hinten an die Platine. Die Schaltung folgt 
heute noch, bin noch nicht dazu gekommen. Wir könnten auch eine Platine 
machen, die an der VGA Seite getrennt werden kann.

Peter Sieg schrieb:
> Ich frage mich nur, wie viele sich für weitere Platinen interessieren..?

5 Stück werden es schon mal, schätze mit der VGA kommen noch einige 
Interessenten dazu.

@alle
Wer hat Interesse an einer Platine? Bitte kurze Mail an mich.

nun erst mal zum Betonieren unterwegs...
Joe

[Peter S. (petersieg)]

@Joe: 1 Platine auf jeden Fall.

Peter

[Joe G. (feinmechaniker)]

VGA/Terminal Schaltung

Hier die Schaltung zur Diskussion. Sie geht auf eine Idee von Sebastian 
B. hier im Forum zurück (siehe 
Beitrag "AVR VGA Terminal")
Ich habe sie auf den ATTmega88 portiert und um eine Farbdarstellung 
erweitert. Wobei das Wort Farbe nicht wörtlich zu nehmen ist. Es wird 
für einen Text immer nur EINE Farbe angezeigt. Der AVR hat nur exakt 8 
Takte um das Zeichen in das Schieberegister zu bringen und da ist keine 
Zeit mehr für die Farbdarstellung jedes einzelnen Zeichens.

Joe

[hschuetz (Gast)]

Hallo Leute,
ich bin noch eine Woche im Urlaub, dann will ich bauen!!
Die Microvga hängt z.Z. am MC CPM Computer wo sie gut funktioniert!
Welche Hardware Version sollte ich bauen und welche Software passt dann 
dazu?? Ich habe vor das System mit der Microvga auszurüsten und kein USB 
zu seriell chip einsetzen. Also bietet die fertige Platine Vorteile? 
oder ist es besser gleich auf Lochraster zu bauen?
Vorschläge sind willkommen
gruß
Hans- Werner

[Hans- w. S. (hschuetz)]

Hallo,
ich bin auch angemeldeter User
Gruß
Hans- Werner

[Peter S. (petersieg)]

Hallo und Willkommen Hans- Werner.

1. Hardware
An Hardware gibt es zur Zeit die fast urspüngliche Version von 
sprite_tm, für
die Joe G. eine kleine Platinenauflage gemacht hat (vergriffen). Aktuell 
sind da nur 2 Leitungen vertauscht um Dramzugriff per Nibble zu 
ermöglichen.
Das kann man natürlich auch auf Lochraster aufbauen.. Schaltplan etc. 
hier weiter oben, im Artikel oder auf meiner Projektseite..
Z.Z diskutieren bzw. planen wir eine Version 2 der Hardware. 
Erweiterungen:
2 x Dramchips mit 4MBit. Dadurch 8-bit Ramzugriff und viel Platz für 
Ramdisk.
MicroVGA direkt anschließbar bzw. sogar ein Selbstbauersatz dazu.

2. Software
Z.Z ist Dank an Leo C. es fast schon schwieriger die jeweils aktuellste 
Version zu flashen ;-) Es gibt auf seiner Seite im trunk Zweig die 
aktuellste Version für die aktuelle 4-bit Dramversion. 8080 CPU 
Emulation
scheint fehlerfrei zu sein, bis zu 4 Partitionen (Typ=52=CP/M) werden 
als
LW a: - d: gemappt. Zusätzlich 64kb Ramdisk als i:
Im Zweig Softuart gibt es die Software für die neue 8-bit Dramversion, 
deren Platine gerade hier diskutiert wird..(2 x Dram Chips).

@Joe G. Das sieht doch prima aus mit dem VGATerm.. wie ich sehe ist da 
auch PS/2 schon dabei.. Sind schon ein paar ESC Codes dekodiert..(CLS?)? 
Lt. Entwickler ist das eng.. Nun Vorteil ist zumindest schon mal, das 
man ein deutsches Tast.Layout einbauen kann.. Und evtl. schaffen wir es 
ja doch noch durch z.B Übertaktung (30-40MHz) zumindest CLS und 
CursorPos zu
implementieren.. ich würde vorschlagen, diese VGA+PS/2 Lösung mit so auf 
die Platinen zu nehmen, das sie wie die MicroVGA-Anschlüsse direkt zu 
funktioniert, wer aber doch MicroVGA möchte (oder nur das..?) dies 
direkt dort durchtrennen kann..

Peter

[Joe G. (feinmechaniker)]

Peter Sieg schrieb:
> Und evtl. schaffen wir es
> ja doch noch durch z.B Übertaktung (30-40MHz) zumindest CLS und
> CursorPos zu
> implementieren..

Die VGA kann leider nicht beliebig übertaktet werden, da der Pixeltakt 
fest steht (25 MHz) und starr mit dem AVR Takt verbunden sein muß. 
Deshalb auch der eigene Quarzoszillator auf der VGA. Ideal wären 
natürlich 50 MHz ;-). Da hätte man dann 8 zusätzliche Takte für den AVR. 
An der Software muß natürlich gearbeitet werden, die Hardware stellt ja 
nur die Experimentierbasis.

Joe

[Horst (Gast)]

Moin moin,
bin gerade über das Projekt gestolpert.
Ich habe mal mit einem ISP8A600 angefangen.
Dann folgten 8080, Z80 und über QRL dann zwangsweise 6502er.
Wobei der Z80 meine lieblings CPU war.
Irgendwo müsste bei mir auch noch eigene CP/M Software sein.
Werde mal suchen. Hatte mal nen eigenen Compiler geschreiben.
Pascal ähnlich, UPN. Compiler erzeugte ASM-Code. Das ganze war für
Steuerungen gedacht.
Ich würde mich gern an das Projekt mit drann hängen.
Leider sind hier keine DRAMs mehr vorhanden.
Wobei wird nocht unterstützung benötigt.
EAGLE, AVRSTUDIO (GCC,ASM) und ein bischen was an Erfahrung sind 
vorhanden.

[Joe G. (feinmechaniker)]

Horst schrieb:
> Ich würde mich gern an das Projekt mit drann hängen.
> Leider sind hier keine DRAMs mehr vorhanden.
> Wobei wird nocht unterstützung benötigt.

Willkommen im Team!
DRAM's sind genug da. Derzeit sehe zwei offene Baustellen.
- dem AVR Z80 Code beibringen
- die VGA programmieren (VGA, PS2, Terminal)

[Peter S. (petersieg)]

@Horst: Auch von meiner Seite ein herzliches Willkommen!

Welche SOJ Dram's kommen jetzt höchstwahrscheinlich zum Einsatz?
4M x 4 SOJ haben 26 Pin?
oder doch die 1M x 4 SOJ mit 24 Pin (Auf der Platine zähle ich 24-Pin's)

Habe ihr dann mal ein paar Bezeichnungen passender Dram's..?
Dann kann ich schon mal meine Bastelkiste durchsuchen..

Peter

[Horst (Gast)]

Moin mion,
OK, ich schau mal in die AVR-Soft rein.
Ich habe hier moch nen MYAVR Smart-Controler liegen.
Hat den schon jemand erweitert?
Ich werde wohl eher beim PC als Terminal bleiben.
VT50/100 müsste ich auch noch mit Pascal oder C-Sourcen irgandwo 
rumliegen haben.

Wenn du noch DRAMS für mich hättest wäre das klasse joe.
Sonst würde ich eine Platine für 8x4164 machen, die sind noch zu 
bekommen.
Das ganze mit SRAM zumachen ist sicher nett, aber die Hardwareanpassung 
wird dann lagsam etwas umfangreich.

Ich könnte z.B. ein Layout für meinen Hardwarebestand machen, 
MYAVR-Smart, 8x4164 plus schon festgelegter Hardwäre von euch. Hat da 
jemand Intresse drann?

Das Übertakten der AVR's muss aus meiner sicht nicht unbedingt sein.
Wenn ich wirklich Tempo haben will wäre eine andere CPU angesagt (ARM ab 
400 MHz).

Netter wäre ein BUS-System um die weitere Hardware auch per AVR zu 
realisieren. Z.B. Ein AVR der Parallelport macht, einen für USB(per 
Software), acht bis zehnmal Servoansteuerung  u.s.w. ES gibt doch schon 
so einiges was man da gut anflanschen könnte. Liesse sich auch alles gut 
ins TINY-Basic ins BIOS einbauen.

[Joe G. (feinmechaniker)]

Peter Sieg schrieb:
> Welche SOJ Dram's kommen jetzt höchstwahrscheinlich zum Einsatz?
> 4M x 4 SOJ haben 26 Pin?

4Mx4 SOJ kommen zum Einsatz. Die haben 24 Pins und werden von 1 bis 26, 
unter Auslassung der 7 und der 20, durchnummeriert. Ein typischer 
Vetreter ist z.B. HY5117404C

Joe

[Joe G. (feinmechaniker)]

Horst schrieb:
> Wenn du noch DRAMS für mich hättest wäre das klasse joe.

Ram's kannst du bekommen, sie sind noch oft auf den alten 
Speicherriegeln zu finden.

>Netter wäre ein BUS-System um die weitere Hardware auch per AVR zu
>realisieren. Z.B. Ein AVR der Parallelport macht, einen für USB(per
>Software), acht bis zehnmal Servoansteuerung  u.s.w. ES gibt doch schon
>so einiges was man da gut anflanschen könnte. Liesse sich auch alles gut
>ins TINY-Basic ins BIOS einbauen.

Hier kannst du dich auch austoben, Pin14/Pin15 der VGA-Schnittstelle 
sind mit I2C belegt (die einzigen freien Pins). Hier kann noch viel 
angeschlossen werden.

Joe

[Leo C. (rapid)]

Peter Sieg schrieb:
> Habe ihr dann mal ein paar Bezeichnungen passender Dram's..?
> Dann kann ich schon mal meine Bastelkiste durchsuchen..

Hier ein Auszug aus meiner Bestandsliste. Die Links auf meine Festplatte 
bitte ignorieren. :-)


72 pol SIMM
-------------------
MT4LC4M4B1DJ-6  Micron    3.3V, 4M x 4
file:///home/leo/Archive/Datenblaetter/Memory/MT4LC4M4B1.pdf


GM71C17403BJ6  LGS      5V, 16M, 4Mx4, 2K Refr, EDO, 60ns
file:///home/leo/Archive/Datenblaetter/Memory/GM71C17403C-7.pdf
http://www.idhw.com/textual/guide/noin_ram_chip_lg.html


HY5117400 JC-70  HYUNDAI  DRAM, 16M, 2K Ref, 4Mx4


HY514400A LJ-60  HYUNDAI    5V, 4M, 1K Refr, 1Mx4,
file:///home/leo/Archive/Datenblaetter/Memory/HY514400ALJ.pdf



VG2617405CJ-6  Vanguard  5V, 4Mb x 4, EDO, 1K Refr,
http://www.idhw.com/textual/guide/noin_ram_chip_vanguard.html


MT4C4M4B1DJ-6  Micron  DRAM, 5V, 4M x4, 2K Refr FPM,
file:///home/leo/Archive/Datenblaetter/Memory/MT4LC4M4B1.pdf
TC514100ASJ-60  Toshiba   5V, 4MB, x1,
file:///home/leo/Archive/Datenblaetter/Memory/TC514100ASJ.pdf





GM71C17400CJ6  LGS  5V, 16M, 2KRefr, 4Mx4, FPM
file:///home/leo/Archive/Datenblaetter/Memory/GM71C17400CJ.pdf
GM71C4100CJ60  LGS   5V, 4M, x1, FPM

[Leo C. (rapid)]

Horst schrieb:
> Moin mion,
> OK, ich schau mal in die AVR-Soft rein.

Hallo Horst,
genau wie Joe würde auch vorschlagen, daß Du Dir dann den 8080 
Interpreter vornimmst. Bevor man ihn auf Z80 aufbohrt, müßte man mal 
schauen, ob sich an der Performance noch was machen läßt. Ich fürchte 
aber, das man das Teil nur schneller bekommt, wenn man wesentlich mehr 
Flash investiert. Und das ist bei Mega8 und Mega88 nicht mehr vorhanden.

> Ich werde wohl eher beim PC als Terminal bleiben.
> VT50/100 müsste ich auch noch mit Pascal oder C-Sourcen irgandwo
> rumliegen haben.

Bei der Gelegenheit könntest Du auch mal einen Wordstar auf VT100/ansi 
anpassen, oder einen angepaßten irgendwo auftreiben. Ich bin immer noch 
nicht dazu gekommen, und kopiere zur Zeit fleißig Dateien zwischen Host 
und Emulator bzw avrcpm hin und her.

> Sonst würde ich eine Platine für 8x4164 machen, die sind noch zu
> bekommen.

Bloß nicht! Viel zu iel Aufwand. Evtl. müßte auch die Software gändert 
werden. Und dann nicht mal eine RAM-Disk.

> Das ganze mit SRAM zumachen ist sicher nett, aber die Hardwareanpassung
> wird dann lagsam etwas umfangreich.


> Ich könnte z.B. ein Layout für meinen Hardwarebestand machen,
> MYAVR-Smart, 8x4164 plus schon festgelegter Hardwäre von euch. Hat da
> jemand Intresse drann?

Hoffentlich nicht. ;-)

> Netter wäre ein BUS-System um die weitere Hardware auch per AVR zu
> realisieren. Z.B. Ein AVR der Parallelport macht, einen für USB(per
> Software), acht bis zehnmal Servoansteuerung  u.s.w. ES gibt doch schon
> so einiges was man da gut anflanschen könnte. Liesse sich auch alles gut
> ins TINY-Basic ins BIOS einbauen.

Kleine Erweiterungen sich sicher ok, aber ein Bus-System würde meiner 
Meinung nach den Rahmen sprengen. --> anderes System.

[Leo C. (rapid)]

A>stat dsk:

    A: Drive Characteristics
 1944: 128 Byte Record Capacity
  243: Kilobyte Drive  Capacity
   64: 32  Byte Directory Entries
   64: Checked  Directory Entries
  128: Records/ Extent
    8: Records/ Block
   26: Sectors/ Track
    2: Reserved Tracks

    I: Drive Characteristics
 8128: 128 Byte Record Capacity
 1016: Kilobyte Drive  Capacity
  192: 32  Byte Directory Entries
    0: Checked  Directory Entries
  128: Records/ Extent
   16: Records/ Block
   32: Sectors/ Track
    2: Reserved Tracks

    J: Drive Characteristics
 8192: 128 Byte Record Capacity
 1024: Kilobyte Drive  Capacity
  192: 32  Byte Directory Entries
    0: Checked  Directory Entries
  128: Records/ Extent
   16: Records/ Block
   32: Sectors/ Track
    0: Reserved Tracks

    K: Drive Characteristics
 8192: 128 Byte Record Capacity
 1024: Kilobyte Drive  Capacity
  192: 32  Byte Directory Entries
    0: Checked  Directory Entries
  128: Records/ Extent
   16: Records/ Block
   32: Sectors/ Track
    0: Reserved Tracks

    L: Drive Characteristics
 7680: 128 Byte Record Capacity
  960: Kilobyte Drive  Capacity
  192: 32  Byte Directory Entries
    0: Checked  Directory Entries
  128: Records/ Extent
   16: Records/ Block
   32: Sectors/ Track
    0: Reserved Tracks


So sieht das jetzt bei mir mit 2 4Mx4 Chips aus.
Für jedes Megabyte ein Laufwerk.
Vom ersten Laufwerk gehen 2 Systemspuren ab (8K), für CCP+BDOS, die von 
dort beim Warmstart neu geladen werden.
Vom letzten Laufwerk gehen 64Kbyte ab. Schließlich bracht der Rechner ja 
auch etwas Arbeitsspeicher. ;-)

Im AVR-Teil sind 32 Sektoren pro Spur und maximal 1 MByte pro Laufwerk 
fest vorgegeben. Die obersten 64K werden immer als Arbeitspeicher 
verwendet.

Der Rest ist über die CP/M Parametertabellen frei einstellbar.
Dafür verwendet man am Besten die Macros, die ich hier mal angehängt 
habe.
Ich war so frei, die DR-Macros für unsere Zwecke etwas anzupassen.

Das ganze kommt auch noch ins SVN, wenn ich etwas aufgeräumt und ein 
paar Build-Scripte erstellt habe.

[Peter S. (petersieg)]

Soo.. ich habe jede Menge 1M x 4 Drams aber kein einziges 4M x 4 Dram.. 
:-(

Peter

[Joe G. (feinmechaniker)]

Noch nicht ganz perfekt aber in diese Richtung wird es gehen...

- VGA kann abgetrennt und separat verwendet werden
- Stromversorgung über Steckernetzteil an VGA
- Bereitstellung von 5V und 3.3V

Joe

[Peter S. (petersieg)]

@Joe: Rx und Tx liegen sich 1:1 gegenüber.. müßten die nicht gekreuzt 
sein?
Und wenn es geht würde ich die Verbindungen, die benötigt werden, wenn 
man beide zusammen betreiben will auch gleich durchverbinden.. dann muß 
man keine Jumper einlöten und verbinden..

Peter

[Horst (Gast)]

moin moin,

war ein langer Tag heute....... mit Familie unterwegs. :-)

Wo ist oder wer hat die aktuelle Software des AVR?

Meine Kisten hatten früher ECB-BUS.
Der uVGA-Bus ist auch OK.
Gibt's schon eine Backplan und ein Gehäuse dafür?
Würde schon lustig ausschauen, so alles auf halben EURO-Kartenformat.

AVR-CPU-Board mit SD-FD und RAM-FD
zweites SD-FD mit RAM-FD
uVGA.
Paralelle IO's.
Serielle IO's.
USB-Master.
Netzwerk.
RFM12-Board für Haussteuerung und ähnliches.
BT, wofür auch immer.
u.s.w

Und wenn dann mal einer Lust hat noch ein ARM-CPU-Board.

Kann was richtig grosses werden :-)

[Ronny M. (hobby-coder)]

was würde ein bauteilesatz der aktuellen version kosten, wenn man avr 
cp/m platine + vgs/ ps2 modul + aller notwendigen bauteile aus einer 
quelle kaufen würde?

[Leo C. (rapid)]

Horst schrieb:
> Wo ist oder wer hat die aktuelle Software des AVR?

http://cloudbase.homelinux.net/viewvc/avr-cpm/

Und hier unter 2. steht noch was dazu:
Beitrag "Re: CP/M auf ATmega88"

> Meine Kisten hatten früher ECB-BUS.
> Der uVGA-Bus ist auch OK.
> Gibt's schon eine Backplan und ein Gehäuse dafür?

Ja, siehe Bild. ;-) [0]

> Würde schon lustig ausschauen, so alles auf halben EURO-Kartenformat.
>
> AVR-CPU-Board mit SD-FD und RAM-FD
> zweites SD-FD mit RAM-FD
> uVGA.
> Paralelle IO's.
> Serielle IO's.
> USB-Master.
> Netzwerk.
> RFM12-Board für Haussteuerung und ähnliches.
> BT, wofür auch immer.
> u.s.w

Wozu das alles auf einem simulierten 8080 mit C/PM?

> Und wenn dann mal einer Lust hat noch ein ARM-CPU-Board.

Für CP/M dann doch eher ein eZ80.

> Kann was richtig grosses werden :-)

Aber mit der Basis, an der wir basteln macht das imho keinen Sinn.


[1] Das ist ein "Schrottteil" von Pollin für einen Euro.
http://www.pollin.de/shop/dt/MTcwOTcyOTk-/Computer_und_Zubehoer/Hardware/Laufwerke_Cardreader/Card_Reader_UCR_61S.html

[Peter S. (petersieg)]

Die neue Platine hat eigendlich drei Neuerungen:
1. 8-bit Dram -> damit ca. Faktor 2 im Dram-Zugriff = ca. doppelt so 
schnell
2. VGA-Terminal (ala MicroVGA) direkt mit auf der Platine (trennbar)
3. I2C Schnittstelle

Einzig 3. eröffnet erweiterte Möglichkeiten.. Hier würde mich 
Interessieren,
was für Möglichkeiten man hier sieht..(Ideen)?

Ansonsten fehlt mir noch eine elegante Möglichkeit mal eine Datei zw. 
CP/M Welt und Host-Welt auszutauschen..

Gäbe XModem (muß noche 8080 Version finden). Ohne MicroVGA sollte das 
direkt klappen.. aber mit wird die serielle Schnittstelle verwendet.. 
MicroVGA hat zwar einen 'Pass Through' Modus.. aber ob das klappt..?
Was gäbe es sonst noch für Möglichkeiten../Ideen..?

Peter

[Joe G. (feinmechaniker)]

Peter Sieg schrieb:
> Rx und Tx liegen sich 1:1 gegenüber.. müßten die nicht gekreuzt
> sein?
> Und wenn es geht würde ich die Verbindungen, die benötigt werden, wenn
> man beide zusammen betreiben will auch gleich durchverbinden.. dann muß
> man keine Jumper einlöten und verbinden..

Ich glaube es ist schon korrekt so, trotzdem bitte nochmal Schaltung und 
Layout überprüfen. Die Belegung ist recht "tricky" deshalb hier mal eine 
Übersicht dazu. Das sollte im späteren Betrieb auch Einstellung 
erleichtern.
Wie ja schon weiter oben beschrieben, können neben der Kommunikation des 
CP/M mit der VGA auch die Varianten CP/M an PC Terminal oder VGA an PC 
Terminal eingestellt werden. Gerade die letzte Variante schein mir zum 
Test und zur Inbetriebnahme der VGA recht nützlich. Außerdem versehe ich 
die AVR im Normalfall mit einem Bootloader, so das über die USB der 
jeweilige Controller programmiert werden kann.
Die Verbindungen CP/M VGA sind schon auf der Platine, sie liegen auf der 
Unterseite.

> Ansonsten fehlt mir noch eine elegante Möglichkeit mal eine Datei zw.
> CP/M Welt und Host-Welt auszutauschen..
Dir gefällt wohl die Variante Vinculum usb nicht? Das CP/M kennt ja 
derzeit noch keine COM xx. Also im AVR die SPI für Vinculum usb 
programmieren und im BIOS als COM xx anmelden.


@Ronny Minow
Ein Bausatz im Sinne von BAUSATZ ist eigentlich nicht geplant. Es wird 
die Platinen und wieder einige Bauelemente (MMC Fassung, SMD IC's, AVR, 
Quarze..) geben.

[Peter S. (petersieg)]

Joe G. schrieb:
> Dir gefällt wohl die Variante Vinculum usb nicht?

Doch. Nur kann ich mir die genaue Funktion noch nicht so richtig 
vorstellen..
Es wird ein USB Stick mit FAT unterstützt. Per seriellen Befehlen wird 
das ganze gesteuert.. Also stelle ich mir das so vor, das im AVR+Bios 
eine 2te serielle Schnittstelle implementiert werden müßte. Dazu dann 
ein passendes Steuerprogramm auf CP/M Ebene das letzlich auch eine Datei 
vom USB Stick lesen und auf CP/M Diskette schreiben kann (und 
umgekehrt..).. Als Alternative könnte auch ein Xmodem diese 2te serielle 
IF nutzen um z.B mit einem PC Daten auszutauschen.. Richtig..?

Peter

[Detlev T. (detlevt)]

Joe G. schrieb:
> Noch nicht ganz perfekt aber in diese Richtung wird es gehen...

Da hätte ich noch ein paar Verbesserungsvorschläge:

1.) Statt des 74HC165 sollte man eher ein 74HC166 nehmen bei dem das 
Laden mit dem Takt synchronisiert ist.
2.) Mir leuchtet nicht ganz ein, wozu die 74HC244 Treiber nötig sind. 
Laut Philips/NXP Datenblatt könnte ein 74HC-Standardausgang problemlos 
4mA treiben, das würde sogar für alle drei Farben gleichzeitig reichen:

$$I = 3 \times \frac{5V}{470\Omega + 75\Omega} = 2.75 mA$$

Gruß, DetlevT

[Horst (Gast)]

Moin moin,

Ich hab mal einen Blick in die Software getan. Schön, aber nicht auf 
Tempo optimert. Da kann man noch reichlich arbeit reinstecken.

1.) Für die Z80 Codes EXX und EX AF,AF' muss noch ein zweiter 
Registersatz her. Ich würde den ins normale SRAM des AVR legen. Diese 
Befehle sind nicht so häufig verwendet worden. Die relativen 
Sprungbefehle sollten kein Problem sein.

2.) Die IN und OUT würde ich wahlweise auf einen der seriellen Busse 
umlegen.
So hat man die möglichkeit damit eigene Hardware zu steuern. Z.B. könnte 
man über I²C oder so PIO's und SIO's anhängen. Ein Mega8 tut per 
software so als ob er eine PIO oder SIO wäre.
Besteht die möglichkeit die uVGA so auch zu steuern?

3.) Für die Interrupt Codes (HALT, u.s.w) bräuchte man noch eine freie 
Portleitung. Ich würde die SD-Floppy auf eine eigene Platine legen ( 
zwei Drives) und an den ser. BUS hängen. So wäre wieder reichlich 
Hardware frei.

Das alles würde auch das BIOS vereinfachen.

[Joe G. (feinmechaniker)]

Detlev T. schrieb:
> Statt des 74HC165 sollte man eher ein 74HC166 nehmen

Gute Idee, schon geändert.

>Mir leuchtet nicht ganz ein, wozu die 74HC244 Treiber nötig sind.

Das waren Relikte aus der s/w Darstellung - auch geändert.

Peter Sieg schrieb:
> Also stelle ich mir das so vor, das im AVR+Bios
> eine 2te serielle Schnittstelle implementiert werden müßte. Dazu dann
> ein passendes Steuerprogramm auf CP/M Ebene das letzlich auch eine Datei
> vom USB Stick lesen und auf CP/M Diskette schreiben kann (und
> umgekehrt..).. Als Alternative könnte auch ein Xmodem diese 2te serielle
> IF nutzen um z.B mit einem PC Daten auszutauschen.. Richtig..?

Ja Peter, genauso dachte ich.

[Hans- w. S. (hschuetz)]

Hallo,
mich würde interessieren wann die neuen Platinen zu erwerben sind..würde 
mich für 2 anmelden.. evtl.mit Spezialteilen...
gruß
Hans Werner

[Joe G. (feinmechaniker)]

Hans- w. Schütz schrieb:
> mich würde interessieren wann die neuen Platinen zu erwerben sind

Wenn jeder Interessent wirklich draufgesehen hat würde ich die 
Bestellung auslösen. Bisher gab es ja noch Änderungen.
Der kalkulierte Preis (Losgröße 10) liegt bei 18,50 pro Stück.
Joe

[Hans- w. S. (hschuetz)]

Das hört sich gut an... merke mich mal für 2 Platinen vor!
Gruß
Hans- Werner

[Detlev T. (detlevt)]

Hallo Joe,

ich bin zwar nicht direkt ein Interessent für Platinen, aber die 
VGA-Geschichte interessiert mich.

Mir ist da eine Unstimmigkeit aufgefallen. Du beziehst dich auf das 
AVR-VGA-Projekt, dass 50 Zeilen a 80 Spalten hat. Das macht einen 
SRAM-Bedarf von 4000 Bytes. Eingeplant hast du ein ATMEGA88 mit 1024 
Bytes.

Es gibt mit dem 328p eine Version mit 2kiB, damit würde man noch 25 
Zeilen schaffen, aber niemals 50. Das dürfte der Grund gewesen sein, 
warum das Original-Projekt den Mega644 (4kiB) nutzt.

Außerdem könnte man mit einem "großen" ATMEGA alle 8 Bit des 
Schieberegister nutzen und mit einem zweiten Port, einem 4-fach 2 zu 
eins Multiplexer (statt AND) und dem DAC wie bei Jörg Wolframs Chipbasic 
für Vorder- und Hintergrundfarbe je eine aus 16 auswählen ohne mehr ICs 
zu brauchen.

Gruß, DetlevT

[Peter S. (petersieg)]

@Joe: Ich denke wir sollten jetzt auch nicht zu schnell die Platinen 
ordern..
Ein paar Tage mehr zum drüber nachdenken, sollte nicht schaden.. Ich 
persönlich finde, das jetzt ohne den VGA-Terminal Part, unser avr cpm 
eigendlich nur von 4 auf 8-bit Ram gewachsen ist (mit dann größerer 
Ramdisk).. ich bin noch nicht gänzlich überzeugt, ob wir nicht mit einem 
größeren AVR (ATmega32/644/1284) mehr gewinnen, mit dem ATmegaX8 sind 
wir mit den Pin's am Ende..

Peter

[Joe G. (feinmechaniker)]

@Peter
Ich habe kein Problem noch einige Tage damit zu warten. Einen größeren 
AVR würde ich auch nicht nehmen. Der Reiz besteht ja gerade darin mit 
einem sehr einfachen System zu arbeiten. Wenn der Programmspeicher nicht 
reicht gibt es ja noch den ATmega168. Benötigt man noch weitere Pins, so 
lässt sich das System bequem über I2C erweitern.

@alle
Hier die letzte Schaltungs- und Layoutversion. Ich würde nun erst mal 
Änderungen, Kritik, Wünsche oder Zustimmungen (Ablehnungen) sammeln, ehe 
ich sie noch mal anfasse.

Joe

[Leo C. (rapid)]

Horst schrieb:
> Ich hab mal einen Blick in die Software getan. Schön, aber nicht auf
> Tempo optimert. Da kann man noch reichlich arbeit reinstecken.

Wunderbar, dann kanns ja losgehen.

> 1.) Für die Z80 Codes EXX und EX AF,AF' muss noch ein zweiter
> Registersatz her. Ich würde den ins normale SRAM des AVR legen.

Klar, und die restlichen, fehlenden natürlich auch. In der 8-Bit 
Variante sind eh schon einige Register ausgelagert.

> Diese
> Befehle sind nicht so häufig verwendet worden. Die relativen
> Sprungbefehle sollten kein Problem sein.
>
> 2.) Die IN und OUT würde ich wahlweise auf einen der seriellen Busse
> umlegen.
> So hat man die möglichkeit damit eigene Hardware zu steuern. Z.B. könnte
> man über I²C oder so PIO's und SIO's anhängen. Ein Mega8 tut per
> software so als ob er eine PIO oder SIO wäre.
> Besteht die möglichkeit die uVGA so auch zu steuern?
>
> 3.) Für die Interrupt Codes (HALT, u.s.w) bräuchte man noch eine freie
> Portleitung. Ich würde die SD-Floppy auf eine eigene Platine legen (
> zwei Drives) und an den ser. BUS hängen. So wäre wieder reichlich
> Hardware frei.
>
> Das alles würde auch das BIOS vereinfachen.

Wir freuen uns auf Deine Verbesserungen und Erweiterungen.

[Ronny M. (hobby-coder)]

@joe g: ok, welche teile kannst du liefern? ich habe noch ein paar edo- 
ram riegel hier liegen. ich müsttste schauen, was das für ram's sind...

kannst du, wennn du die platinen in die fertigung gibts, eine material 
liste erstellen, damit ich evtl. fehlende teile bestellen kann?

wie trennt ihr eigendlich die vga platine von der avr cpm platine? ich 
denke, eine pinleiste, um die signale per jumper verbinden/ trennen zu 
können, sollte ausreichen...

[Joe G. (feinmechaniker)]

Detlev T. schrieb:
> Mir ist da eine Unstimmigkeit aufgefallen. Du beziehst dich auf das
> AVR-VGA-Projekt, dass 50 Zeilen a 80 Spalten hat. Das macht einen
> SRAM-Bedarf von 4000 Bytes. Eingeplant hast du ein ATMEGA88 mit 1024
> Bytes.

Der ATmega88 steht in der Schaltung nur stellvertretend (EAGLE 
Footprint) für den ATmega328. Zum Einsatz kommen soll tatsächlich der 
328. Das gibt dann genau die von dir genannten 25 Zeilen zu 80 Spalten.

Ja, es könnten mehr Ports, ein DAC, ein Multiplexer... aber auch ein 
CPLD oder ein FPGA verwendet werden. Ich habe aus zwei Gründen darauf 
verzichtet.

1. Das AVR CP/M ist bewusst mit sehr einfacher Hardware aufgebaut, 
sozusagen ein minimalistisches System. So soll es auch bleiben. Mich 
schmerzt eigentlich schon das dritte IC. Es ist keine Konkurrenz für 
ARM's, eZ80, ... Ein Schüler mit Bastelerfahrung und einer kleinen 
Kramkiste soll es aufbauen können und ein vollwertiges Betriebsystem mit 
allen dazugehörigen Tools nutzen können.

2. Die VGA soll die gleichen Bedingungen erfüllen. Bunte Buchstaben 
(außer grün auf Schwarz ;-) ) machen da eigentlich keinen Sinn.

3. Mit der microVGA gibt es schon etwas für diejenigen die mehr wollen.

Joe

[Horst (Gast)]

Moin moin,

hat mal einer für den MYZ80 Emu ein Disk-Images mit DDTZ drinn für mich?
Bräuchte ich mal fürs testen.

[Leo C. (rapid)]

Horst schrieb:
> hat mal einer für den MYZ80 Emu ein Disk-Images mit DDTZ drinn für mich?
> Bräuchte ich mal fürs testen.

Auf die Schnelle hatte ich nicht rausgefunden, wie man beim MYZ80 in und 
aus den Diskimages kopiert. Bin dann beim simh hängen geblieben.
Z80-Simulator im DOS-Emulator muß ja auch nicht sein. :-)

Im Anhang ein nackter DDTZ.COM. War im simh Disk-Image schon drin.
Dort geht rein und raus mit den mitgelieferten Programmen R.COM und 
W.COM.

[Horst (Gast)]

Moin moin,

danke Leo.
Kannst du mal schauen ob du das darein bekommst?

[Leo C. (rapid)]

Horst schrieb:
> Moin moin,
>
> danke Leo.
> Kannst du mal schauen ob du das darein bekommst?

Sorry, was soll das sein?

[Horst (Gast)]

Das ist das Disk-images für den MYZ80.
Ich hatte die Hoffnung das du (oder wer auch immer) mir da mal den DDTZ 
einbauen könnte. :-)

[Joe G. (feinmechaniker)]

Ronny Minow schrieb:
> kannst du, wennn du die platinen in die fertigung gibts, eine material
> liste erstellen, damit ich evtl. fehlende teile bestellen kann?

Ja, kann ich, kann aber EAGLE auch mit dem oben reingestellten Files.

> wie trennt ihr eigentlich die vga platine von der avr cpm platine?
Mit der Säge ;-)

Die genaue Bestellliste gebe ich bekannt, wenn wir das KGV gefunden 
haben.

Joe

[Peter S. (petersieg)]

Von meiner Seite ok. Einzig ich habe keine 4M x 4 Dram Chips.. habt ihr 
davon genug (1M x 4 habe ich jede Menge.. aber die dürften ja nicht 
passen)?

Peter

[Detlev T. (detlevt)]

Joe G. schrieb:
> Ein Schüler mit Bastelerfahrung und einer kleinen
> Kramkiste soll es aufbauen können und ein vollwertiges Betriebsystem mit
> allen dazugehörigen Tools nutzen können.
>
> 2. Die VGA soll die gleichen Bedingungen erfüllen. Bunte Buchstaben
> (außer grün auf Schwarz ;-) ) machen da eigentlich keinen Sinn.

Ich schaue vor allem auf den VGA-Teil (wird dich nicht überraschen) und 
kann da deine Argumente nicht ganz nachvollziehen.

Kaum einer wird alle Teile in seiner "Kramkiste" finden. Den relativ 
neuen ATMEGA328p auch sicher seltener als den häufig genutzten 
ATMEGA644. Letzterer ist auch bei den üblichen Verdächtigen (Pollin, 
Reichelt,...) im Angebot, der 328p nicht.

Wenn man schon eine Leiterplatte hat, macht ein 74HC157 einzulöten auch 
nicht mehr Mühe als ein 74HC08. Der Preis ist auch fast gleich.

PS: Ich hatte mir jetzt gerade noch einmal den Schaltplan vom AVR-VGA 
angesehen. Da ist mir aufgefallen, dass dort ein 74*AC*08 als AND-Gatter 
vorgesehen war. Das erklärt, warum die Treiber noch nachgeschaltet 
werden mussten. Die AC können praktisch keinen Strom liefern.

[Frank M. (ukw) (Moderator)]

Detlev T. schrieb:

> Kaum einer wird alle Teile in seiner "Kramkiste" finden. Den relativ
> neuen ATMEGA328p auch sicher seltener als den häufig genutzten
> ATMEGA644. Letzterer ist auch bei den üblichen Verdächtigen (Pollin,
> Reichelt,...) im Angebot, der 328p nicht.

Den ATMEGA328P-PU gibt es zum Beispiel bei CSD.

Gruß,

Frank

[Detlev T. (detlevt)]

ERRATUM

Detlev T. schrieb:
> 2.) Mir leuchtet nicht ganz ein, wozu die 74HC244 Treiber nötig sind.
> Laut Philips/NXP Datenblatt könnte ein 74HC-Standardausgang problemlos
> 4mA treiben, das würde sogar für alle drei Farben gleichzeitig reichen:

Da habe ich mich doch glatt um eine Größenordnung vertan. In 
Wirklichkeit sind es nicht 2.75mA, sondern 27.5mA. Das schafft man mit 
einem HC-Ausgang natürlich nicht mehr.

[Peter S. (petersieg)]

Ich hänge hier mal die partlist aus eagle dran..

Hier ein Auszug ohne C, R, Jumper etc.:

Part     Value          Package      Library  
B1       DBDB101G       DB           rectifier 
CON1     SCDA5A0201     SCDA5A0201   SCDA5A0201 
IC1      ATmega88-20P   DIL28-3      atmel   
IC2      74S08D         SO14         74xx-eu 
IC3      FT232RL        SSOP28       ftdichip
IC4      ATmega88-20P   DIL28-3      atmel   
IC7      74AC08D        SO14         74xx-eu 
IC8      LF50CDT        DPACK        v-reg   
IC9      LF33CDT        DPACK        v-reg   
IC10     74HC166D       SO16         74xx-eu 
J1       DCJ0202        DCJ0202      con-jack 
LED1     Grün           LED3MM       led   
LED2     Gelb           LED3MM       led   
LED3     Grün           LED3MM       led   
QG1      25 MHz         DIL14S       crystal 
QG2      25 MHz         DIL14S       crystal 
U$1      DRAM_4M_4      SOJ26-24     AMESYS  
U$2      DRAM_4M_4      SOJ26-24     AMESYS  
X1       PN61729-S      PN61729-S    con-berg 
X2       PS2            SSV-BC06     con-yamaichi 
X3       VGA            HDF15H       con-subd

Dazu ggf. noch ein paar Hinweise..
FT232RL und entsprechende Bauteile + USB Buchse braucht man nur, wenn 
man diese PC Verbindung auch nutzen möchte..
Ich gehe davon aus, das der SD Slot auch mit der Platine geliefert 
werden kann (wie beim letzten mal..)
Der AVR CP/M läuft bei mir stabil mit 30MHz. In ein paar Tagen bekomme 
ich 40MHz Quarzoszillatoren und weiß dann, ob es auch damit geht.. d.h, 
wer seinen AVR CP/M höher takten möchte, sollte anstatt 1x25MHz dann 
einen höher getakteten Quarzoszi bestellen..

Peter

[Peter S. (petersieg)]

Ich habe hier noch mal verschiedene 'Meßwerte' aus weiter oben zusammen 
getragen:

-------------------------------------------------------
           |  Peters  |        Leos        |
           | Schleife |      Schleife      |
-----------+----------+--------------------+-----------
AVR   MHz  | Zeit [s] | Zeit [s]   "Speed" | HW    SW    
-----------+----------+---------+----------+-----------
 88   20     35.999                           original hardware
-------------------------------------------------------
 88   20     21.380                           4     (unoptimized code)
 168  24     17.620                           4     (unoptimized code)
 88   25     16.871                           4     (unoptimized code)
 8    20     12.180                           4     0
 8    20     12.453      3.488     827 KHz    4     1
 8    20     11.500      3.488     827 KHz    4     3
 88   30      7.573                           4     ?
-------------------------------------------------------
 8    20      7.599      2.039    1380 KHz    8     2
 8    20      6.680      2.039    1380 KHz    8     3
-------------------------------------------------------
 8    20      6.418      1.958    1470 KHz    8     4
-------------------------------------------------------
 *** Hochrechnung ***
 88   40      5.6                ~1600 KHz    4     ?
 X8   30      4.3                ~1800 KHz    8
 X8   40      3.25               ~2000 KHz    8

"HW 4" ist die jetzt aktuelle 4-bit Verdrahtung und "HW 8" die 8-Bit Variante.

D.h z.Z liegt man bei 4-bit und Übertaktung bei ca. 1,3MHz 8080 Speed.
Das erreicht man ebendso mit 8-bit Dram Ansteuerung ohne Übertaktung.
Mit 8-bit + Übertaktung sind ca. 2MHz 8080 Speed drin..
Und noch weitere Optimierungen des Codes kommen on Top.

Peter

[Joe G. (feinmechaniker)]

Detlev T. schrieb:
> Wenn man schon eine Leiterplatte hat, macht ein 74HC157 einzulöten auch
> nicht mehr Mühe als ein 74HC08.

Wozu dann der Multiplexer? Um während der Schwarzschulter die 
Hintergrundfarbe einzustellen?

[Detlev T. (detlevt)]

Joe G. schrieb:
> Wozu dann der Multiplexer? Um während der Schwarzschulter die
> Hintergrundfarbe einzustellen?

Der Multiplexer wird vom Ausgang des Schieberegisters angesteuert. Er 
schaltet dann immer die einen oder die anderen 4 Bit durch, die auf 
einem (zweiten) Port ausgegeben werden. 4 Bit= Rot Grün Blau und 
Intensität. Damit könnte man dann Vorder- und Hintergrundfarbe frei 
aus einer Palette von 16 Farben wählen. Auch ein anders farbiger Rahmen 
wäre möglich, wenn man die ISR etwas erweitert.

[Joe G. (feinmechaniker)]

Detlev T. schrieb:
> Der Multiplexer wird vom Ausgang des Schieberegisters angesteuert.

OK, verstanden. Es gibt nur leider keine 2x4 Bit die frei sind, d.h. 
doch einen größeren Controller zu nutzen. Aber genau das sollte ja nicht 
sein.

Ich sehe einfach folgendes Problem. Zunächst wird sehr sehr ausführlich 
über die Hardware diskutiert (ist auch gut so). Die Hardware ist jedoch 
nur die halbe Miete. Es gehört natürlich noch eine entsprechende 
Software dazu. Die Softwarediskussion bzw. die Mitarbeit ist meist 
umgekehrt proportional zur Hardwarediskussion (ist nicht gut so).
Mein Vorschlag. Wenn die Software auf der SimpleVGA ordentlich und 
stabil läuft, es einige nachgebaut und getestet haben, dann gibt es eine 
nette 80x50 Farbvariante.
Joe

[Joe G. (feinmechaniker)]

Detlev T. schrieb:
> PS: Ich hatte mir jetzt gerade noch einmal den Schaltplan vom AVR-VGA
> angesehen. Da ist mir aufgefallen, dass dort ein 74*AC*08 als AND-Gatter
> vorgesehen war. Das erklärt, warum die Treiber noch nachgeschaltet
> werden mussten. Die AC können praktisch keinen Strom liefern.

Mein Datenblatt sagt mir, dass gerade der AC-Type 24mA treibt.

[Detlev T. (detlevt)]

Joe G. schrieb:
> Es gehört natürlich noch eine entsprechende
> Software dazu. Die Softwarediskussion bzw. die Mitarbeit ist meist
> umgekehrt proportional zur Hardwarediskussion

Ist klar. Ich mache ja nur Vorschläge, die Entscheidung triffst du.

An dem Quelltext würde sich allerdings nicht viel ändern. Du musst ja 
jetzt schon die drei Bits für die Farbe an einem Port ausgeben, das wäre 
dann halt stattdessen ein ganzes Byte. Die Ausgabe-Routine würde sich 
gar nicht ändern, allenfalls die Bezeichnung der Pins, die vermutlich 
ein einziges mal irgendwo definiert werden. Dafür könnte man dann den 
Standard 8x16 Font einer VGA-Karte nutzen, während du jetzt irgendwo 
einen 6x16 Font auftreiben musst, weil du nur 6 Bits ins Schieberegister 
schreiben kannst.

PS: Ich habe schon ein kleines C-Programm geschrieben, dass einen 
VGA-Font erst einmal komplett einliest und die Daten dann als C-Datei 
wieder ausgibt. Das auf Assembler-Ausgabe umzustricken ist kein großer 
Akt. Sage Bescheid, wenn du Interesse daran hast.

[Joe G. (feinmechaniker)]

@alle

Wir gehen nun langsam in die Bestellphase. Ich bitte alle Interessenten 
wie beim letzen mal um eine kurze Mail an "feinmechaniker", damit ich 
sie in den Verteiler aufnehmen kann. Weiterhin bitte die Anzahl der 
Platinen und der möglicherweise noch benötigten Bauelemente mitteilen. 
Wer meine Kontaktdaten schon hat, natürlich auch direkt ;-)

Schon erfasst sind:

Peter S. x Platinen
Peter Z. 1 Platine
Hans-Werner S. 2 Platinen, aber noch ohne Kontaktmail
Ronny Minow x Platinen

Noch mal einige Worte zur Hardware.
AVR CP/M:
Die neue Variante wird eine 8 Bit RAM Variante sein. Die alte 4 Bit 
Variante läuft stabil. Die neue 8 Bit Variante ist in dieser Form der 
erste Neuaufbau. Eine Versuchsschaltung auf LR läuft aber schon bei Leo 
C.
Auch ist das neue Layout noch nicht getestet. Es könnten (was ich nicht 
hoffe) noch Fehler drin sein. Alle Nachbauinteressenten sollten sich 
also darüber im Klaren sein so was wie "Betatester" zu sein.

AVR VGA:
Diese Schaltung ist eine reine Experimentiervariante für eigene 
Versuche. Die Grundidee basiert auf einer Schaltung von Sebastian B. 
hier im Forum (siehe Beitrag "AVR VGA Terminal"). Mein LR Aufbau erzeugt 
derzeit die H- und V-Synchronimpulse und die Datenpixel. Hier besteht 
also noch jede Menge Handlungsbedarf.

microVGA:
Die Anschlüsse an der AVR CP/M Platine liegen Pinkompatibel zur 
Beschaltung der microVGA. Hier gibt es mindestens zwei funktionierende 
Systeme (Peter's und mein eigenes). Die microVGA bedient allerdings nur 
ein englisches Tastaturlayout sowie eine maximale Baudraute von 38400.

Joe

[Hans- w. S. (hschuetz)]

Hat denn schon jemand das VGA Term in gange gebracht??
Hab ja die VGAterm hat aber Ihren preis...die Alternative wäre schon 
interessant. Na schaun wir mal..
Gruß
Hans- Werner

[Peter S. (petersieg)]

Wohl kaum. Lt Joe existiert der Code für ATmega16.. müßte also erst an 
328 angepasst werden.. Evtl. wäre es auch angebracht, für das VGATerm 
einen extra Thread auszumachen.. könnte mehr Leute interressieren, die 
mit CP/M wenig anfangen können/wollen.. auch um ggf. noch mehr für 
Platinen zu
interessieren..

Peter

[Horst S. (h3aau)]

Moin moin,

Die ersten Aenderungen für den Z80-Emu sind fertig.

Neuer opcode-Interpreter
EX AF,AF'
EXX
Relative Jumps

Da ich noch keine Hardware habe bräuchte ich mal jemanden der die 
Software
testen kann. Wer hat Lust und für welchen AVR soll ich es compilieren?

[Joe G. (feinmechaniker)]

Horst S. schrieb:
> Da ich noch keine Hardware habe bräuchte ich mal jemanden der die
> Software
> testen kann.

Sende mir doch einfach die Quelle zu und ich stelle sie über SVN bereit.
Joe

[Peter S. (petersieg)]

Horst S. schrieb:
> Neuer opcode-Interpreter
> EX AF,AF'
> EXX
> Relative Jumps

Das alles sagt mir nicht soo viel ;-)
Ist der z80 jetzt damit komplett drin..?

Generell kann ich schon testen.. aber bei dem kleinsten Problem.. geht 
das dann wie ein Ping-Pong Spiel los.. ist halt sicher nicht ideal ohne 
eigene Hardware.. Hast du das für die 4-bit Dram oder die 8-bit 
Dramversion gemacht?
Außer Leo C. dürfte z.Z wohl eher niemand die 8-bit Hardware haben.. ;-)
---
Nun, ich habe die 4-bit Version (3x) hier. 30MHz. 38400 Baud.
Ich habe Sargon.com (Schachprogramm) auf einer 'Diskette'. Das Programm 
steigt mit illegel Opcode aus, da es vermutlich z80 Code enthält..
---
Alternativ kann ich auch 1 x 4-bit Hardware verkaufen (-> Mail).

Peter

[Dagobert (Gast)]

Gibt es irgendwo eine Tabelle mit den Steuercodes für die Sondertasten? 
Es wäre dann möglich, VGATerm speziell für das System umzuschreiben. 
Würde dann diese Spezial-Version liefern, falls dies gewünscht wird.

[Joe G. (feinmechaniker)]

Die originalen VGA Quellen findet ihr nun auch hier: 
http://www.mikrocontroller.net/svn/list

[Horst S. (h3aau)]

Moin moin,

@joe
>Sende mir doch einfach die Quelle zu und ich stelle sie über SVN bereit.

danke, aber so völlig ungetestet möchte ich das nicht in die weite welt 
verteilen. wenn es zur zeit nur einen mit 8bit HW gibt wäre es wohl ganz 
gut wenn ich meine änderungen auch in die 4bit SW einbaue. ich bin nach 
schlechten erfahrungen bei anderen projekten kein freund von svn mehr. 
kannst du die SW irgend wo für einen normalen download bereitstellen?

@Peter Sieg
danke fürs angebot, sende mir das mal als PM zu.
ich hätte schon gern die 8Bit hardware wann sind die platinen den so 
weit?
ich lasse meine sonst immer beim platinenbelichter machen. ist die DRAM 
verfügbarkeit/beschaffung eigentlich schon geklärt?
ich denke ich habe hier die SW als 8bit version.
leider ist in der SW selber keine doku und/oder change history drinn.

[Leo C. (rapid)]

Horst S. schrieb:
> danke, aber so völlig ungetestet möchte ich das nicht in die weite welt
> verteilen.

Wenn die Software nicht verfügbar ist, kann sie nicht getestet werden...

> ich denke ich habe hier die SW als 8bit version.

Mir scheint, das nicht nur wir hier im Dunkeln tappen...
Hast Du keine Hardware, auf der Du testen kannst?

Wenn Du Deine Software (noch) nicht nicht ins Forum stellen willst, dann 
schick sie mir doch bitte per Email. Ich kann Dir dann sagen, welche 
Version Du hast, und auf welcher Hardware sie laufen würde. Außerdem 
kann ich dann auch gene mal was testen.

[Leo C. (rapid)]

Hallo Horst,

prinzipiell läuft Dein Interpreter. So siehts im Moment aus:

CPM on an AVR, v1.0

Testing RAM: fill...wait...reread...

Initing mmc...
CP/M partition at: 001, size: 7811KB.
CP/M partition at: 15624, size: 7812KB.
CP/M partition at: 31248, size: 7812KB.
Partinit done.
Ok, CPU is live!

ipl
62k cp/m vers 2.2

Danach sollte der CP/M Prompt "A>" kommen....

Der Bootloader (ipl) wird ausgeführt, der Anfang vom BIOS.
Im Bios hängt das Programm zuerst in der Console-Inputschleife (wo es 
garnicht hinkommen sollte), und danach endlos in der Bootschleife, weil 
der avr-teil beim Sektor lesen immer einen Fehler zurückmeldet.

Ich habe den Verdacht, das bei call/return etwas schief läuft.


Horst S. schrieb:
> wenn es zur zeit nur einen mit 8bit HW gibt wäre es wohl ganz
> gut wenn ich meine änderungen auch in die 4bit SW einbaue.

Im Moment scheine ich der einzige zu sein, der die 8-Bit Variante 
aufgebaut hat. Es reicht aber, wenn Du Deine Software einmal schreibst. 
Vorläufig kann ich sie dann in die verschiedenen Versionen integrieren.

Auf längere Sicht möchte ich aber nur noch eine Version haben, 
allerdings modularisiert. Vielleicht sollte ich das jetzt endlich mal 
machen.

> ich bin nach
> schlechten erfahrungen bei anderen projekten kein freund von svn mehr.

Ohne Versionsverwaltung wirds aber echt schwierig mit mehreren Leuten an 
einem Projekt. Oder richtet sich Deine Aversion speziell gegen 
Subversion, und eine andere Versionsverwaltung wäre ok?

> ich denke ich habe hier die SW als 8bit version.
> leider ist in der SW selber keine doku und/oder change history drinn.

Die change history ist im svn.
Die Doku ist hier im Thread. ;-)
Ansonsten: "Use the source luke!" ;-)
Im Source sind ganz oben die Ports definiert. Dort kannst Du sehen, das 
für das RAM nur 4 Datenbits definiert sind.

Die aktuellen Quellen sind hier:

http://cloudbase.homelinux.net/viewvc/avr-cpm/trunk/
Das ist die "stabile" Version für die aktuelle (4-Bit-RAM) Hardware.

http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/softuart/
Hier ist z.Zt. die Version für 8-Bit RAM.

Sorry für svn.

[Joe G. (feinmechaniker)]

Leo C. schrieb:
> Die Doku ist hier im Thread. ;-)

Es muss ja nicht jeder programmieren oder Hardware entwerfen. Vielleicht 
findet sich hier einer der sich mal an eine ordentliche Doku macht.

Gibt es noch Interessenten für die neue LP? Alle von mir schon Erfassten 
sollten im Mailverteiler sein, aber möglicherweise habe ich noch 
jemanden vergessen. Einfach bei mir melden.

[Hans- w. S. (hschuetz)]

Hallo Leute,
wenn mein System endlich läuft werde ich es dokumentieren und alles auf 
meiner Webseite veröffentlichen....
Wer seine Softwareversionen dann mit veröffentlichen will...
kein Problem.
Webseite schuetz.thtec (dot)org
Gruß
Hans- Werner

[Leo C. (rapid)]

@Horst

> Der Bootloader (ipl) wird ausgeführt, der Anfang vom BIOS.
> Im Bios hängt das Programm zuerst in der Console-Inputschleife (wo es
> garnicht hinkommen sollte), und danach endlos in der Bootschleife, weil
> der avr-teil beim Sektor lesen immer einen Fehler zurückmeldet.

Ich habe nochmal etwas genauer hingeschaut: Der Fehler ist ein völlig 
anderer.

> Ich habe den Verdacht, das bei call/return etwas schief läuft.

Jetzt habe ich einen anderen Verdacht, aber ich muß noch suchen.

[Horst S. (h3aau)]

moin moin,

danke Leo. da scheint sich noch ein fehler in der todo_table 
eingeschlichen zu haben. ich werde die noch mal überprüfen. kannst du 
über die debugfunktion noch irgend was an infos sehen?
ich müsste sonst jeden möglichen opcode von hand testen. :-(

[Leo C. (rapid)]

Horst S. schrieb:

> danke Leo. da scheint sich noch ein fehler in der todo_table
> eingeschlichen zu haben. ich werde die noch mal überprüfen. kannst du
> über die debugfunktion noch irgend was an infos sehen?
> ich müsste sonst jeden möglichen opcode von hand testen. :-(

Einen Fehler habe ich inzwischen gefunden. In meinem BIOS ist aber auch 
ein Fehler.

Die Details schicke ich Dir per E-Mail, sonst wird das hier zuviel.

[Horst S. (h3aau)]

moin moin,

aua, das klingt nach einer etwas grösseren baustelle.....

[Leo C. (rapid)]

Horst S. schrieb:
> aua, das klingt nach einer etwas grösseren baustelle.....

Ich glaube eher an ein, zwei, klitzekleine. Aber bis man die gefunden 
hat,...

[Detlev T. (detlevt)]

Hallo Joe,

Joe G. schrieb:
> 1. Das AVR CP/M ist bewusst mit sehr einfacher Hardware aufgebaut,
> sozusagen ein minimalistisches System. So soll es auch bleiben. Mich
> schmerzt eigentlich schon das dritte IC.

Nur Interesse halber: Gibt es (außer der Möglichkeit der Farbänderung 
per Software) einen Grund für den 74AC08? Könnte man, wenn man mit weiß 
auf schwarz zufrieden wäre, da als Impedanzwandler nicht einen einfachen 
Emitterfolger nutzen.(z.B. mit BF199: max. 100mA / 400MHz 
Transitfrequenz) Statt eines ICs wäre das dann nur ein Transistor und 
ein paar Widerstände.

Gruß, DetlevT

[Joe G. (feinmechaniker)]

Detlev T. schrieb:
> Gibt es (außer der Möglichkeit der Farbänderung per Software) einen Grund für 
den 74AC08?

Nein gibt es nicht, ist nur für Nostalgiker wie mich die gerne grün auf 
schwarz oder amber auf schwarz möchten, so wie es früher war...
Ansonsten ist natürlich auch ein schneller Transistor ausreichend.

Joe

[Joe G. (feinmechaniker)]

Detlev T. schrieb:
> Mich
>> schmerzt eigentlich schon das dritte IC.

Das hatte ich glatt überlesen. Das ditte IC bezog sich auf die reine AVR 
CP/M Schaltung, also ohne VGA. Hier kam gegenüber der Urvariante noch 
der 74VHC08 als Pegelwander der MMC dazu. Das wurde notwendig um den AVR 
und RAM sicher mit 5V laufen zu lassen.
Joe

[Ronny M. (hobby-coder)]

hallo joe g,

kannst du dram's, bzw. sram's, für das board (je nach varainte) liefern? 
falls nicht, ich habe hier noch ein paar edo ram riegel liegen. ob man 
die bausteine verwenden kann, muss ich mal prüfen... ich habe eine gute 
anzahl dieser riegel liegen. aber, welche bauteine man hiervon verwerten 
kann, muss ich erst testen...

amsonten: kannst du evtl. sogar alle benötigten bauteile liefern? in 
form eines bauatzes versteht sich. falls nicht, nehme ich die passenden 
dram's/ sram's und die beiden platinen (avr cp/m platine + vga platine).

[Horst S. (h3aau)]

Moin moin,

gibt es eigentlich schon eine Version mit SRAM?
Den 628512 und 74HC374 gibt es günstig und als DIL.
Wenn schon Bastelkisteprojekt dann am besten auch ohne SMD.

[Detlev T. (detlevt)]

@Horst S.
Damit solltest du besser nicht rechnen. Die DRAMs werden hier ja auch 
als RAM-Disk benutzt, da fehlt beim SRAM der Platz. Außerdem würde sich 
da vielleicht auch eher ein ATMEGA8515 oder 162 anbieten, der ein 
SRAM-Interface in Hardware mitbringt. Ganz weit oben wurde das kurz 
einmal andiskutiert, dann aber halt ein anderer Weg gegangen.

@VGA
Das ist der Teil, der mich eigentlich interessiert. Ich habe einmal eine 
Impedanzwandlerschaltung mit einem Transistor simuliert. (R5-R7 ist der 
VGA-Monitor)

Sieht alles ziemlich gut aus. Die Flankensteilheit wird maßgeblich vom 
Eingangssignal bestimmt. Der Transistor allein schafft etwa 3ns 
(10%<->90%).Nur die Abrundung am Ende der steigenden Flanke ist ein 
Artefakt des Verstärkers allein. Der Eingangsstrom bei "ON" liegt bei 
etwa 5mA, 6mA Spitze beim Schalten. Also etwas, was ein 74HC166 ohne 
Hilfe noch so schafft.

Packt es als Memo zu den Akten. Vielleicht kommt die Frage bei einer 
späteren Version wieder auf, wenn man den Aufbau weiter vereinfachen 
will. Das hier soll keine Kritik an der aktuellen Hardware sein.

Die "ASC"-Datei ist die Simulation. Falls noch jemand damit spielen 
will.

[Horst S. (h3aau)]

moin moin
mal eine frage an die asm-profis hier.

.dw label erzeugt 2byte mit der adr des label. so weit ok.
.dd low(label) erzeugt leider auch 2byte und eine warnung.
beides möchte ich aber nicht, sonder nur das lowbyte der adr.

ich arbeite mit avr-studio.
schon mal danke.

[Horst S. (h3aau)]

sorry .dd ist natürlich .db

[spess53 (Gast)]

Hi

>.dd low(label) erzeugt leider auch 2byte und eine warnung.
>beides möchte ich aber nicht, sonder nur das lowbyte der adr.

Der Flashspeicher der AVR ist Word-Organisiert. Daran lässt sich nichts 
ändern.

MfG Spess

[Peter S. (petersieg)]

Kurze Info bez. Übertakten: 40MHz bei 3,3V geht nicht mehr. 30MHz läuft 
stabil. Bei 5V kann das natürlich trotzdem noch mit 40MHz klappen (muß 
aber nicht).

Peter

[Horst S. (h3aau)]

moin moin

hat sich erledigt, habe eine lösung gefunden.

[Joe G. (feinmechaniker)]

Der Chinamann hat gerade den Produktionsstart der Leiterplatten 
bestätigt, nun läuft die Zeit.

[Horst S. (h3aau)]

Moin moin,

Die 8080 Version ist so weit fertig.
Der Code passt noch locker in einen ATMega8.
Es ist noch Platz für zusätliche Wünsche.

Der Z80 hat über 700 Befehle, das passt leider nicht
mehr in die 8K. Hier für ist dann ein ATMega168 nötig.

Im wessentlichen habe ich den Opcode-Interpreter etwas auf Tempo
gebracht und für den Z80 vorbereitet.

Wer weiter mit arbeiten möchte kann sich direkt bei mir melden.

Danke noch mal an Leo fürs Testen da ich selbst noch keine
Schaltung habe.

Wie schaut es mit der Hardware aus?
Neue Ideen, neue Wünsche?

[Leo C. (rapid)]

Horst S. schrieb:

> Die 8080 Version ist so weit fertig.

Wenn Du meinst. ;-)

Wie wärs, wenn man z.B. die Tabellen über Makros aufbauen würde. Z.B. 
so:

; instr fetch, op, store
;
.macro  instr  
  .db  low(@2), low(@1), high(@1), low(@0)
.endm

;--------------------------------------------------

    instr do_fetch_DIR16, do_nop,     do_store_BC   ;01 nn nn ;LD BC,nn
    instr do_fetch_DIR8,  do_op_CPFA, do_nop        ;FE nn    ;CP n

Nur mal zwei Befehle als Beispiel. Die Tabellen wären übersichtlicher, 
und bei Änderungen an der Tabellenstruktur müßte man nur das Makro 
ändern.


> Im wessentlichen habe ich den Opcode-Interpreter etwas auf Tempo
> gebracht und für den Z80 vorbereitet.

So sieht es jetzt aus:

 Zeit   "Speed"  HW     Interpreter
 [s]     [KHz] 
--------------------------------------
3.364     857    4      alt
3.173    1088    4      neu (Horst S.)
1.924    1499    8      alt
1.753    1645    8      neu (Horst S.)

Hardware mit 4bit/8bit-RAM, jeweils bei 20MHz.

>
> Wer weiter mit arbeiten möchte kann sich direkt bei mir melden.
>
> Danke noch mal an Leo fürs Testen da ich selbst noch keine
> Schaltung habe.

Wie man an der Tabelle sieht, läuft es jetzt auch mit der neuen 
Hardware.
Ich habe nochmal eine Kleinigkeit am Interpreter ändern müssen, weil die 
fetch- und store-routinen (dank der RAM-Makros in der 8-Bit Version) 
nicht mehr zusammen in eine Page passen.

Ich habe angefangen, das Programm in mehrere Dateien zu zerlegen.
Die Struktur, wie das Ganze werden soll, kann man sicher schon erkennen.
Es gibt jetzt einen neuen Schalter, mit dem man die 8-Bit oder 4-Bit 
auswählen kann. Weitere Schalter, zb. für die Größe des RAMs, sind 
geplant. Die RAM-Disk ist z.Zt. gerade abgeschaltet. Wer 
(Verbesserungs-) Vorschläge hat, bitte (hier) melden. Ich suche z.B. 
noch nach einer Möglichkeit, die DRAM-Makros zu verunübeln.

Die neueste Version habe ich hier angehängt. Demnächst kommt sie auch 
ins SVN. Z.Zt. in branches/modules. Später, wenn alle damit glücklich 
sind, nach trunk.

Gute Nacht

[Joe G. (feinmechaniker)]

Horst S. schrieb:
> Wie schaut es mit der Hardware aus?

Die LP kommen am 27.08. Die restliche HW bestelle ich spätestens morgen, 
es fehlen noch Zuarbeiten.

[Horst S. (Gast)]

Moin Moin,

Frühstückspause!
und schnell die Tabelle gebaut. Gut das ich die in Excel verwalte.
Baust du das noch mit ein Leo? Danke.
Ich kümmere mich weiter um den Z80.

Danke.

[Peter S. (petersieg)]

@Leo C + Horst S: SUPER!! Herzlichen Dank! Mit euch kommt das Projekt 
softwaretechnisch wirklich in 'ungeahnte Dimensionen' ;-)
(..and boldly go were no one has gone before..)

Prima!
(Habe gerade mal die 4-bit Version durch den Assembler gejagt;
heute nachmittag kann ich es erst den AVR flashen.. dann mehr..)

Peter

[h3aau (Gast)]

und hier noch mit vertauschten fetch und store......

[Peter S. (petersieg)]

Evtl. ist das von Nutzen..?

Beitrag "Software UART mit FIFO"

Peter

[Peter S. (petersieg)]

Ups.. das war es noch nicht ganz für die 4-bit Version:

Booten:

Initing mmc...
CP/M partition at: 401625, size: 8032KB.
CP/M partition at: 417690, size: 8032KB.
CP/M partition at: 433755, size: 8032KB.
Partinit done.
Ok, CPU is live!

        A =80 BC =0000 DE =0000 HL =0000 SP =08B0 PC =2000       31 00 10 
        A =80 BC =0000 DE =0000 HL =0000 SP =1000 PC =2003       CD 35 20 

--- dann das hier geändert ---

#define K 1024
#define M 1204*K

#define RAMSIZE 256*K*4  /* 1 chip 256Kx4 */
;#define  RAMSIZE   4*M*4 * 2  /* 2 chips 4Mx4  */

#define RAMDISKCNT 0    /* Number of RAM disks *

--- und das hier geändert ---

.equ INS_DEBUG   = 0

--- Fehler beim assemblieren ---

C:\cpmtools\avr2\8080int.asm(1278): info: macro 'mem_read_d' called here
C:\cpmtools\avr2\avrcpm.asm(56): info: 'C:\cpmtools\avr2\8080int.asm' included from here
C:\cpmtools\avr2\dram-4bit.asm(88): error: Relative branch out of reach
C:\cpmtools\avr2\8080int.asm(1280): info: macro 'mem_read_d' called here
C:\cpmtools\avr2\avrcpm.asm(56): info: 'C:\cpmtools\avr2\8080int.asm' included from here
C:\cpmtools\avr2\avrcpm.asm(66): No EEPROM data, deleting C:\cpmtools\avr2\avrcpm.eep

Assembly failed, 9 errors, 0 warnings

Peter

[Leo C. (rapid)]

Peter Sieg schrieb:
> Ups.. das war es noch nicht ganz für die 4-bit Version:
> [code]
> Booten:
>
> Initing mmc...
> CP/M partition at: 401625, size: 8032KB.
> CP/M partition at: 417690, size: 8032KB.
> CP/M partition at: 433755, size: 8032KB.
> Partinit done.
> Ok, CPU is live!
>
>         A =80 BC =0000 DE =0000 HL =0000 SP =08B0 PC =2000       31 00
> 10
>         A =80 BC =0000 DE =0000 HL =0000 SP =1000 PC =2003       CD 35
> 20

Also hat schon mal was funktioniert. Was war das denn?

> --- dann das hier geändert ---
>
> #define K 1024
> #define M 1204*K
>
> #define RAMSIZE 256*K*4  /* 1 chip 256Kx4 */
> ;#define  RAMSIZE   4*M*4 * 2  /* 2 chips 4Mx4  */

Das ist bisher nur so 'ne Idee. Wird noch nirgens ausgewertet.
Das ist auch ein Grund, warum die RAM-Disk abgeschaltet ist.
>
> #define RAMDISKCNT 0    /* Number of RAM disks *
>
> --- und das hier geändert ---
>
> .equ INS_DEBUG   = 0

Das hatte ich vor dem Veröffenltlichen vergessen.
Wenns aber mit dem Schalter lief, muß es ohne den auch laufen.

Es wäre schön gewesen, wenn Du etwas genauer aufgeschrieben hättest, was 
Du genau übersetzt hast.

> --- Fehler beim assemblieren ---
..
> C:\cpmtools\avr2\dram-4bit.asm(88): error: Relative branch out of reach
...

Die Fehler bekomme ich jetzt auch, wenn ich für Mega328P assembliere.
Mal sehen, ob ich die mit ein bischen Code-verschieben weg bekomme.

[Peter S. (petersieg)]

Leo C. schrieb:
> Es wäre schön gewesen, wenn Du etwas genauer aufgeschrieben hättest, was
> Du genau übersetzt hast.

ok. Sorry.

Zuerst für ATmega88 übersetzt. kein Fehler dabei.
Dann aber die debug Meldungen..

Und da ich immer einen 168 / 88 im Wechsel nutze, dann debug 
ausgeschaltet
und für 168 übersetzt.. dabei die 9 Fehlermeldungen..

CPM on an AVR, v1.0

Testing RAM: fill...wait...reread...

Initing mmc...
CP/M partition at: 401625, size: 8032KB.
CP/M partition at: 417690, size: 8032KB.
CP/M partition at: 433755, size: 8032KB.
Partinit done.
Ok, CPU is live!
ipl

62k cp/m vers 2.2

A>dir


A: ASM      COM : DDT      COM : DUMP     COM : ED       COM
A: T        COM : TLOOP    COM : LOAD     COM : MBASIC   COM
A: 23       BAS : BAGELS   BAS : CHECKERS BAS : STARTREK BAS
A: TREKINST BAS : MASTRMND BAS : WEEKDAY  BAS : PIP      COM
A: STAT     COM : SUBMIT   COM : XSUB     COM : ZORK1    COM
A: ZORK1    DAT
A>t b



Timer running. Elapsed: 007.004s.
A>

Also ich korrigiere mich.. für 88 läuft das!! Nur im 168/328 Zweig
gibt es die angesprochenen Probleme..
Und von 7,589s auf 7,004s runter ;-) (30MHz)

Mea culpa.

Peter

[Leo C. (rapid)]

Peter Sieg schrieb:
> ok. Sorry.

Ich habe halt etwas länger suchen müssen. Alle "sinnvollen" 
Kombinationen liefen bei mir. Mega328 mit 4-Bit ist bei mir nicht 
sinnvoll, weil ich gerade keine Hardware dafür habe. ;-) Ob's durch den 
Assembler läuft, teste ich aber trotzdem gelegentlich.

So wie im Anhang, müßte es jetzt gehen. Mit dieser Lösung bin ich aber 
keinesfalls glücklich. Wer das ganze Paket mal in Form bringen will, 
soll sich keinen Zwang antun...

Auf längere Sicht wird man bei den größeren Prozessoren nicht mehr ohne 
absolute Sprünge auskommen. Die können ja nicht "hinten rum" springen, 
wie der 8 oder 48.


> Und von 7,589s auf 7,004s runter ;-) (30MHz)

More to come...  stay tuned.

Edit: sorry für die zip.zip Datei. Kann man so ein Versehen nicht wieder 
löschen?

[Leo C. (rapid)]

Peter Sieg schrieb:
> Evtl. ist das von Nutzen..?
>
> Beitrag "Software UART mit FIFO"

ELIZA würde wahrscheinlich antworten:
"CAN YOU ELABORATE ON THAT?"

[Leo C. (rapid)]

Horst S. schrieb:
> und schnell die Tabelle gebaut. Gut das ich die in Excel verwalte.
> Baust du das noch mit ein Leo? Danke.

Ist drin.
Im SVN und in dem Paket, das ich gerade gepostet habe.
Könnte Dein Excel-Exporter auch die Leerräume genau so formatieren, wie 
ich es jetzt gemacht habe? Die Tab-Breite ist dabei auf 8 Eingestellt.

[Horst S. (h3aau)]

Moin moin,

ich suche noch jemanden der die todo_tabs für die Z80-oopcodes füllt.
ist eine fleissarbeit, würde aber helfen.
hat jemand lust?

[Peter S. (petersieg)]

@Horst S.: Hänge es mal hier rein und sage was ich machen muß.. dann 
kümmere ich mich morgen drum..

@Leo C.: 168 Zweig assembliert ohne Fehler und läuft auch. Prima!

Peter

[Leo C. (rapid)]

Horst S. schrieb:

> ich suche noch jemanden der die todo_tabs für die Z80-oopcodes füllt.
> ist eine fleissarbeit, würde aber helfen.
> hat jemand lust?

Gut, daß Du das selber hier reinstellst, ich wollte Deine E-Mail schon 
umleiten. ;-)

Peter Sieg schrieb:
> @Horst S.: Hänge es mal hier rein und sage was ich machen muß.. dann
> kümmere ich mich morgen drum..

Das ist eine gute Frage. Mir ist das auch nicht klar. Das dürfte nämlich 
sehr stark vom Interpreter abhängen, der ja auch noch nicht da ist.

Die wenigen Befehle, die in der jetztigen Tabelle fehlen, wird Horst 
nicht meinen.

Für 0xDD und 0xFD braucht man imho gar keine Tabellen. Das sind 
Umschaltprefixe für Befehle mit H, L, HL, (HL) als Operanden.

0xED ist nur schwach besetzt. Da wird man vielleicht eine irgendwie 
komprimierte Tabelle machen.

CB ist sehr regelmäßig. Da kann man wahrscheinlich auch was machen, um 
nicht eine 3 oder 4 mal 256 Byte Tabelle anlegen zu müssen.

Andererseits, wenn man mit größerem Prozessor mindestens 8KByte 
zusätzlichen Tabellenplatz hat...


> @Leo C.: 168 Zweig assembliert ohne Fehler und läuft auch. Prima!

Danke fürs Testen.

[Horst S. (h3aau)]

Ist eigentlich recht einfach.
do_fetch_xxx      ; woher kommen die daten LD ??,A = do_fetch_A
do_store_xxx      ; wo sollen sie hin      LD A,?? = do_store_A

im zweifelsfall einfach do_???? eintragen.

do_op_xxx         ; hier steck die eigentliche finktion

im zweifelsfall bei do_op_xxxx einfach do_op_inv eintragen.

[Peter S. (petersieg)]

Hier mal einige Einträge im Tab: cb + ed.
Bitte prüfen, ob ich das so richtig verstanden+gemacht habe..?
Dann ziehe ich auch die anderen durch..

Peter

[Peter S. (petersieg)]

Hier noch der Rest, den ich soweit gefüllt habe..

Peter

[Horst S. (Gast)]

Danke Peter,
Schaut schon ganz gut aus.
Ich werde zum Wochenende mal eine Rohversion für den Z80 fertig machen 
und an Leo senden.
Soll ich mal eine Beschreibung machen wie der Opcode-Interpreter nun 
arbeitet?

Gruus Horst

[Peter S. (petersieg)]

Horst S. schrieb:

> Soll ich mal eine Beschreibung machen wie der Opcode-Interpreter nun
> arbeitet?

Aber immer und gerne!
Den Aufruf von Leo C. zur Dokuerstellung habe ich auch nicht vergessen.. 
nur
macht das erst Sinn, wenn das Projekt sich noch etwas mehr 'gesetzt' 
hat.. z.Z ist noch viel zu viel im Umbruch (zum Besseren = Gut so!)..

Peter

[Leo C. (rapid)]

Im Anhang sind meine neuesten Spielereien. Es sind zwei neue 
Interpretervarianten. Hier mal eine Tabelle mit den Unterschieden:

 Interpreter   |             [.cseg]            |avrdude|Laufzeit|"Speed"
               |   End      Code   Data   Used  |       |   [s]  | [KHz]   
---------------+----------+------+------+-------+-------+--------+--------
z80int           0x001900   5052   1178   6230     6400    1.924   1499
8080int          0x001b00   4848   1690   6538     6912    1.733   1644
8080int-t3       0x001b00   4936   1434   6370     6912    1.733   1644
8080int-t3-jmp   0x001d00   5240   1434   6674     7424    1.366   2111

-t3 heißt, dasß die Opcode-Tabelle von 4 auf 3 Byte je Eintrag reduziert 
wurde. Spart 256 Byte Tabellenplatz, kostet aber 88 Byte zusätzlichen 
Code für eine Sprungtabelle. Witzigerweise genau gleiche Laufzeit, wie 
die 4-Byte Variante. Eine Optimierung ist mir dann aber noch 
eingefallen. War eigentlich für die -t3-jmp Variante gedacht, dort aber 
nicht anwendbar.;)

8080int-t3       0x001b00   4934   1434   6368     6912    1.712   1684

-t3-jmp: Statt push/return in der Interpreterschleife wird zwischen den 
Phasen 'load', 'do_op' und 'store' direkt gesprungen. Kostet Platz, der 
aber noch vorhanden ist.

Meinungen würden mich interessieren.


Peter Sieg schrieb:
> Den Aufruf von Leo C. zur Dokuerstellung habe ich auch nicht vergessen..

Der (konstruktive) Vorschlag war von Jörg.
(Nach einer ironischen Bemerkung von mir zum Thema.)

[Leo C. (rapid)]

Peter Sieg schrieb:
> Hier noch der Rest, den ich soweit gefüllt habe..

@Peter, @Horst:

> do_op_ADC
> do_op_SBC

Nach der bisherigen Nomenklatur müßten diese wohl do_op_ADCHL und 
do_op_SBCHL heißen.

Aber in den DD/FD-Tabellen gibts ja auch noch IX und IY als 
Zielregister.

Vorschlag:

op_ADDHL  --> op_ADD16
op_ADC    --> op_ADC16
op_SBC    --> op_SBC16

Allgemeiner Vorschlag:
In den (Excel-) Tabellen grundsätzlich

do_fetch_xxx  --> fetch_xxx
do_op_xxx     --> op_xxx
do_store_xxx  --> store_xxx

Das "do_" wird (nur) bei Bedarf über die Makros wieder zugefügt.

[Horst S. (Gast)]

Moin moin,
Leo. schrieb:

< Meinungen würden mich interessieren.

Guter Trick das vom Stack in Register zu verlegen.
Damit bin ich bei meiner Frage die ich dir eigentlich zusammen mit der 
Z80-Rohversion zusenden wollte.
Wie ist den nun die Registeraufteilung für den Z80?
Eigentlich wollte ich die neu festlegen und dort einiges aufräumen.
Die bestehende Áufteilung ist für den 8080 ja ok.
Kann man eigentlich noch Code in den DRAM-Routinen sparen?
Hier wird doch auch reichlich Zeit verbraten.

Gruss Horst

[Leo C. (rapid)]

Horst S. schrieb:
> Wie ist den nun die Registeraufteilung für den Z80?
> Eigentlich wollte ich die neu festlegen und dort einiges aufräumen.

Sicher möglich. Als endgültig festgemauert sehe ich da noch nichts.
Die 2 Register, die ich für die serielle Schnittstelle reserviert habe, 
kann man wahrscheinlich freischaufeln. Allerdings muß der RX-Code 
unbedingt noch überarbeitet und getestet werden.

> Kann man eigentlich noch Code in den DRAM-Routinen sparen?
> Hier wird doch auch reichlich Zeit verbraten.

Möchtest Du Code oder Zeit einsparen?

Ich weiß nicht, ob Du Dir die 8-Bit Version schon angeschaut hast, aber 
dort habe ich massig Code gegen Zeit eingetauscht (Macros statt 
Unterprogramme).
An unkritischen Stellen kann man sicher wieder Unterprogrammaufrufe 
einbauen, und so etwas Flash einsparen, wenns eng wird.

Ansonsten ist die DRAM-Ecke ausgereizt. Imho. Jedenfalls mit den beiden 
Hardwarevarianten, die wir jetzt haben.

Ach ja, in den DRAM-Routinen ist zur Zeit über die config-Datei ein (1) 
"wait state" eingestellt. Bei schnellen RAMS kan man den weglassen. Das 
sieht dann so aus:

               |             [.cseg]            |avrdude|Laufzeit|"Speed"
               |   End      Code   Data   Used  |       |   [s]  | [KHz]   
---------------+----------+------+------+-------+-------+--------+--------
-jmp             0x001d00   5240   1434   6674     7424    1.366   2111
 "  (jp to main) 0x001b00   5000   1434   6434     6912    1.449   1990
 " " (0 wait st) 0x001b00   4954   1434   6388     6912    1.415   2038

Wegen der Makros spart das 46 Byte Flash. Geschwindigkeit brings aber 
gar nicht so viel. Bei der Interpretervariante, die ich gerade teste, 
hebt es aber den Speed-Faktor wieder über die magische 2 Mhz Marke. ;-)

[Horst S. (h3aau)]

Moin moin,

Leo C. schreib:
>Möchtest Du Code oder Zeit einsparen?

Zeit, das ist schliesslich Sinn und Zweg der Übung. Wie bekomme ich eine 
möglichst schnelle Simulation der Ziel-CPU hin. Ob die RAM-Floppy 1 oder 
2 Sekunden braucht ist mir da völlig egal.
Wenn wir dabei bleiben ATMega8 = 8080 und ATMega168 = Z80 hast du noch 
reichlich Flash zum spielen. :-)

Wobei ich ja immer noch mit einem SRAM liebäugle.(Joe, wie wäre es?)

Wieviel Codes braust du eigentlich für einen normalen DRAM read/write?
Dann könnte man mal abschätzen ob das noch Tempo bringt.

Gruss Horst

[Peter S. (petersieg)]

Leo C. schrieb:
> -t3-jmp: Statt push/return in der Interpreterschleife wird zwischen den
> Phasen 'load', 'do_op' und 'store' direkt gesprungen. Kostet Platz, der
> aber noch vorhanden ist.
>
> Meinungen würden mich interessieren.

My 2 cents:
Dank Joe G. sind ja die 4-bit HW Version 1 mit 168 AVR's ausgeliefert..
Wir haben also max. 16kb zur Verfügung.. das sieht bei z.Z ca. 6,5kb 
also
noch nach 'reichlich' Luft aus.. (auch für den z80 Interpreter)..
Und ansonsten dient der 328 als 'letzte' Reserve..

Aber genauso wichtig wie speed ist die Übersichtlichkeit und 
Verständlichkeit des Code!

Daraus folgt:
Speed vor kleinerem Code, solange Code übersichtlich und verständlich 
bleibt.

Peter

[Leo C. (rapid)]

Horst S. schrieb:
> Wobei ich ja immer noch mit einem SRAM liebäugle.(Joe, wie wäre es?)

Zum 100000ten mal: Die Kombination SRAM und ATmega8 (48..328) macht 
überhaupt keinen Sinn und ist ein völlig anderes Projekt. Lass Dich 
nicht davon abhalten und mach einen neuen Thread auf.

Deine restlichen Fragen sind Durch einen einfach Blick in den Sourcecode 
zu beantworten.

[Peter S. (petersieg)]

Und läuft (88 - 30MHz - 4-bit):

CPM on an AVR, v1.0

Testing RAM: fill...wait...reread...

Initing mmc...
CP/M partition at: 401625, size: 8032KB.
CP/M partition at: 417690, size: 8032KB.
CP/M partition at: 433755, size: 8032KB.
Partinit done.
Ok, CPU is live!
ipl

62k cp/m vers 2.2

A>dir


A: ASM      COM : DDT      COM : DUMP     COM : ED       COM
A: T        COM : TLOOP    COM : LOAD     COM : MBASIC   COM
A: 23       BAS : BAGELS   BAS : CHECKERS BAS : STARTREK BAS
A: TREKINST BAS : MASTRMND BAS : WEEKDAY  BAS : PIP      COM
A: STAT     COM : SUBMIT   COM : XSUB     COM : ZORK1    COM
A: ZORK1    DAT
A>t b



Timer running. Elapsed: 006.212s.
A>

Down to 6,212s ;-)

BTW: Meldet sich immer noch mit Version 1.0..? Sollte man da nicht mal
den Zähler etwas höherstellen.. so 1.x und wenn z80 drin ist 2.x..

Was mögliche, künftige HW Redesigns angeht.. wurde schon mehrfach 
angesprochen.. Jörg Wolfram hatte Überlegungen dazu.. aber mangels
Interesse (von möglichen Usern) diese nicht weiter verfolgt..
Ich schlage vor, insbesondere, da ja gerade die 8-bit Version erst
noch gebaut wird (von der 'Masse') ersteinmal hier an der vorhandenen
Basis weiter zu arbeiten.. dann mal sehen, was die Zukunft zu bringt..
Wichtiger als der Ram ist für mich ggf. I2C Hardware und deren 
Einbindung
ins CP/M..

Peter

[Leo C. (rapid)]

Ich habe mal wieder was neues ausprobiert. D.h., eigentlich habe ich nur 
schon dagewesenes neu zusammengewürfelt.

                 |   End      Code   Data   Used  |     |  [s]  | [KHz]
-----------------+----------+------+------+-------+-----+-------+-------
letzte schnellste 0x001d00   5240   1434    6674   7424   1.366   2111
neu               0x001f00   6492    666    7158   7936   1.206   2391

Die Tabellen sind jetzt in Form von r/jmp/call/s von Data nach Code 
gerutscht. Leider belegen sie so aber nochmal deutlich mehr Platz.



Peter Sieg schrieb:
> Und ansonsten dient der 328 als 'letzte' Reserve..

Hier wollte ich jetzt hinschreiben, daß das hier das ideale Projekt für 
den ATmega8 ist, weil der deutlich billiger ist, als seine Nachfolger. 
Das scheint sich aber gerade zu ändern. Der 8 ist im Moment weder bei 
CSD noch bei Reichelt lieferbar. Und CSD hat einen neuen Preis, der 
deutlich über dem 88 liegt.

> Aber genauso wichtig wie speed ist die Übersichtlichkeit und
> Verständlichkeit des Code!

An der Übersichtlichkeit hat sich imho bisher nichts geändert, da das 
Interpreterprinzip ja immer noch das gleiche ist. Und wenns 
unverständlich ist, liegst vielleicht nur an der Doku. ;-)

> BTW: Meldet sich immer noch mit Version 1.0..? Sollte man da nicht mal
> den Zähler etwas höherstellen.. so 1.x und wenn z80 drin ist 2.x..

Bei mir gibts keine Versionen, nur Revisionen der einzelnen Dateien. ;)
Ich will schon seit längerem eine Funktion einbauen, die beim booten die 
Revisionen der wichtigsten Teile anzeigt.

Vielleicht möchte ja jemand den "Releasemanager" spielen, und 
ausgesuchte Revisionen als Version x.x.x taggen.

[Leo C. (rapid)]

Peter Sieg schrieb:
> A>t b
>
>
>
> Timer running. Elapsed: 006.212s.
> A>
>
> Down to 6,212s ;-)

Kann ich ja auch mal:

A>t b

Timer running. Elapsed: 003.988s.
A>

[Peter S. (petersieg)]

Leo C. schrieb:
> Timer running. Elapsed: 003.988s.
> A>

Ja, aber das ist 8-bit Dram ;-)
Warte mal bis ich auch meine 8-bit Version aufgebaut habe und den
direkt mitbestellten 40MHz Quarzosi draufgesteckt habe ;-) ;-)

Peter

[Leo C. (rapid)]

Hallo,

das avrcpm ist inzwischen ja wirklich schnell genug, um Ladder zu 
spielen. Vor ca. 25 Jahren war ich danach regelrecht süchtig. :-)
Die Configuration über LADCONF.COM funktioniert bei meinem Terminal 
(minicom, VT-100/ANSI) nicht richtig. Deshalb habe ichs manuell 
angepaßt, und in der Initialisierung auch den störenden Cursor 
abgeschaltet. Mit dem "Programm" CURON.COM kann man den Cursor nach dem 
Spielen wieder einschalten. Ich habe mal alles zusammen gepackt und 
hier angehängt.

Ansonsten habe ich aus der 4-bit DRAM-Leseroutine nochmal 4 Taktzyklen 
rausgequetscht. Aus der Schreibroutine leider nur einen. Das geht, weil 
durch die Zusammenlegung mit der 8-Bit-Variante jetzt auch hier das 
_255-Register vorhanden ist. Leider habe ich nicht ausprobiert, wie viel 
das gebracht hat.

Dafür habe ich aber mal wieder eine Tabelle von der 8-bit Version:
[code]
         --PUSH/POP--     --CALL/RET--     -----DEC-----    Flash
          [s]   [MHz]      [s]   [MHz]      [s]    [MHz]    [byte]
------------------------------------------------------------------
z80int   1.924  1.499     1.971  1.792     6.291   1.467     2426
8080int  1.732  1.665     1.831  1.861     5.911   1.561     2734
 -t3     1.712  1.684     1.811  1.882     5.842   1.580     2564
 -t3-jmp 1.367  2.109     1.466  2.325     4.707   1.961     2762
 -jmp    1.206  2.391     1.281  2.660     3.988   2.314     3272
[code]

Unter DEC ist die Schleife von Peter. Ich habe dafür auch mal die 
Taktzyklen gezählt, damit man die auch mal in ein Z80-Äquivalent 
umrechnen kann. Unter MHz steht also jeweils die Frequenz, mit der ein 
echter Z80 laufen müßte, um das gleiche Ergebnis wie mein 20MHz AVR zu 
erzielen.

Unter Flash steht nur der Speicherverbrauch des Interpreters. Das 
restliche Programm ist bei allen Zeilen gleich.

[Peter S. (petersieg)]

Leo C. schrieb:
> Unter DEC ist die Schleife von Peter. Ich habe dafür auch mal die
> Taktzyklen gezählt, damit man die auch mal in ein Z80-Äquivalent
> umrechnen kann.

Jup. Wie viele Zyklen hast du denn gezählt?

Na, Ladder werde ich doch dann mal probieren.. ;-) Danke!

Gruß Peter

[Leo C. (rapid)]

Peter Sieg schrieb:
> Jup. Wie viele Zyklen hast du denn gezählt?

023E 3E 01      MVI  A,01
0240 D3 40      OUT  40
0242 0E 0A      MVI  C,0A   ;7                              7\
0244 06 00      MVI  B,00   ;7                   7\           |
0246 3E 00      MVI  A,00   ;7         7\          |          |
0248 3D         DCR  A      ;4  \        |         |          |
0249 C2 0248    JNZ  0248   ;10 / 14*256 |3605*256 |922901*10 |
024C 05         DCR  B      ;4         4 |         |          |
024D C2 0246    JNZ  0246   ;10       10/          |          |
0250 0D         DCR  C      ;4                   4 |          |
0251 C2 0244    JNZ  0244   ;10                 10/           |
0254 3E 0F      MVI  A,0F   ;7                              7 |
0256 D3 40      OUT  40     ;11                            11/
0258 C9         RET         ;                 Gesamtzahl Takte: 9229035

Ich hoffe, daß ich mich nicht verzählt habe.

[Peter S. (petersieg)]

Soo.. mußte mir ersteinmal ein vernünftiges VT100 Terminalprogramm für 
Vista
laden (TeraTerm) ;-)

Prima! Macht Spaß mit Ladder..

Peter

[Peter S. (petersieg)]

Hmm.. gerade mal wieder versucht für 168 zu übersetzen (t3-jmp):

C:\cpmtools\avr3\avrcpm.asm(59): Including file 'C:\cpmtools\avr3\remainders.asm'
C:\cpmtools\avr3\avrcpm.asm(63): Including file 'C:\cpmtools\avr3\8080int-t3-jmp.asm'
C:\cpmtools\avr3\dram-4bit.inc(88): error: Relative branch out of reach
C:\cpmtools\avr3\8080int-t3-jmp.asm(1374): info: macro 'mem_read_d' called here
C:\cpmtools\avr3\avrcpm.asm(63): info: 'C:\cpmtools\avr3\8080int-t3-jmp.asm' included from here
C:\cpmtools\avr3\dram-4bit.inc(88): error: Relative branch out of reach
C:\cpmtools\avr3\8080int-t3-jmp.asm(1376): info: macro 'mem_read_d' called here
C:\cpmtools\avr3\avrcpm.asm(63): info: 'C:\cpmtools\avr3\8080int-t3-jmp.asm' included from here
C:\cpmtools\avr3\avrcpm.asm(73): No EEPROM data, deleting C:\cpmtools\avr3\avrcpm.eep
Assembly failed, 2 errors, 0 warnings

Peter

[Leo C. (rapid)]

Peter Sieg schrieb:
> C:\cpmtools\avr3\dram-4bit.inc(88): error: Relative branch out of reach

Hallo Peter,
Du könntest mal dieses hier versuchen:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/avrcpm/

Dort habe ich u.a. mal wieder alles so hingeschoben, daß alle Funktionen 
mit relativen Sprüngen und Calls erreichbar sind. Bei mir kann ich 
fehlerfrei übersetzen. Allerdings habe ich die 4-bit Version nicht 
getestet.

[Leo C. (rapid)]

Gestern Abend habe ich mal einen Wordstar 3.0 an das VT-100 Terminal 
angepaßt. Da ich gerade ein CP/M Diskimage parat hatte, habe ich es mal 
mit angehängt. In der Zip-Datei sind nur die Dateien. WS.COM ist der 
angepasste Wordstar, und WSU.COM das Original.

[Peter S. (petersieg)]

Jup:

CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 401625, size: 8032KB.
CP/M partition at: 417690, size: 8032KB.
CP/M partition at: 433755, size: 8032KB.
Partinit done.
Ok, CPU is live!
ipl

62k cp/m vers 2.2

A>t b

Timer running. Elapsed: 005.182s.
A>

und schon wieder schneller geworden.. ;-)

Danke, Peter

[Horst S. (h3aau)]

Moin moin,

mal ein kleiner Zwischenbericht von der Fleißarbeit.

Alle Opcodes des Z80 aufgelöst, es sind etwas über 700.
Splitten der Tabellen fertig.
Paging der IX,IY Opcodes fertig.
CB Opcodes gehen alle.
ED Opcodes am debuggen.

Der Z80 hat parallel zu den 8080 Opcodes noch einige weitere.
Diese werden mittels Prefix , also voran gestelltem Opcode, eingeleitet.
Der Prefix CB leitet z.B. BIT Opcodes ein.
Der Prefix ED leitet z.B. IN/OUT und Block-Opcodes ein.
Diese können wie die 8080 Opcodes über Tabellen abgearbeitet werden.

Der Prefix DD leitet alle IX Opcodes ein.
Der Prefix FD leitet alle IY Opcodes ein.
In diesen Fällen werden die Opcodes die das HL Register verwenden so 
umgebogen das nun das jeweilige I-Register verwendet wird.
In diesen Fällen ist es einfacher die Routinen für FETCH und STORE zu 
ändern, den nur sie sind davon betroffen.
Alle zusammen passen in eine 256 Byte Page. Das Highbyte dieser Page 
wird in main schon getrennt behandelt. Ich muss die geänderten Routinen 
also nur auf getrennten Pages ablegen und kann dann bei den 8080 Opcodes 
die gewünschte FETCH/STORE Page verwenden.

Ein Nachteil dieses Verfahrens ist das in diesen vier Fällen main 
doppelt durchlaufen wird.
Der Vorteil ist das die Standart-Opcodes ohne zusätzlichen Zeitverlust 
abgearbeitet werden.

Gruß Horst

[Peter Z. (flexopete)]

Moin,

habe mal angefangen nach der Artikelbeschreibung ein diskimage
zu erstellen. Benutzt habe ich cpmtools für Windows. Die avrcpm
habe ich mit Notepad erstellt.
mkfs.cpm kommt mit einer Fehlermeldung:
unknown format avrcpm.

Was mache ich falsch?

Gruß
Peter

[Leo C. (rapid)]

Peter Zabel schrieb:
> zu erstellen. Benutzt habe ich cpmtools für Windows. Die avrcpm
> habe ich mit Notepad erstellt.

Welche avrcpm meinst Du denn?
Die cpmtools sollten irgendwo eine Datei mit Diskdefinitionen haben.
Bei mir heißt diese Datei "diskdefs". Diese Datei muß man um einen 
"avrcpm"-Eintrag erweitern:

diskdef avrcpm
  seclen 128
  tracks 77
  sectrk 26
  blocksize 1024
  maxdir 64
  skew 1
  boottrk 2
  os p2dos
end

> mkfs.cpm kommt mit einer Fehlermeldung:
> unknown format avrcpm.
> Was mache ich falsch?

Entweder findet Dein mkfs.cpm die Datei "diskdefs" nicht, oder in der 
Datei fehlt der Eintrag "avrcpm". Wie die Datei unter Windows 
normalerweise heißt, und wo sie dort liegen muß, kann ich Dir nicht 
sagen.

[Joe G. (feinmechaniker)]

Unter Windows heißt sie auch diskdefs und sollte im gleichen Verzeichnis 
wie mkfs.cpm.exe liegen.
Wenn dd unter Windows später Probleme macht, dd mit Adminrechten 
ausführen.
Joe

[Peter Z. (flexopete)]

Die diskdefs liegt im gleichen Verzeichnis wie mkfs.cpm.exe
und ist um den Eintrag avrcpm erweitert. Trotzdem gibt
es die Fehlermeldung "unknown format avrcpm". Was kann es noch
sein?

Peter

[Joe G. (feinmechaniker)]

Versuche es mal mit dieser Datei.
Joe

[Peter Z. (flexopete)]

OK, damit geht es, danke. In Deiner diskdefs sind nur 2 Formate.
Ich werde die originale mal abmagern, um mal zu sehen, woran
es liegt.
Ich habe noch eine Frage zu dd. Als output file steht dort
< sd card identifier >. Ist das das Linux device, wie eine
LiveCD die SD card finden würde, z.B. /dev/sde ?

Peter
PS: CSD hat Betriebsferien bis zum 04.09.

[Joe G. (feinmechaniker)]

Mit dd --list kannst du dir alle deine Speichermedien anzeigen lassen. 
Dann kopierst du einfach den entsprechenden Eintrag raus. Bei mir sieht 
es z.B. so aus: of=\\?\Device\Harddisk5\Partition0
Bei Linux ist es einfacher, da ist es so wie du es schon beschrieben 
hast.
Joe

[Peter S. (petersieg)]

Peter Zabel schrieb:
> Die diskdefs liegt im gleichen Verzeichnis wie mkfs.cpm.exe
> und ist um den Eintrag avrcpm erweitert. Trotzdem gibt
> es die Fehlermeldung "unknown format avrcpm". Was kann es noch
> sein?
>
> Peter

Jup.. da habe ich auch etwas gesucht ;-) Die Antwort ist so simpel wie
das Program doof ist.. Notepad fügt ein CR ans Ende der Zeile.. das 
können
aber die cpmtools unter Windows gar nicht ab ;-)

Also:
1. Die cpmtools MÜSSEN unter X:\cpmtools liegen
2. Die diskdefs muß mit Unix Konvention als Zeilenende (nur LF) sein

Dann geht es.. garantiert..

Peter

[Peter Z. (flexopete)]

Moin,
habe jetzt das diskimage auf die SD gebracht. Das dd aus den
UNIX-Tools für Windows kennt kein --list. Das dd 0.6beta3
von John Newbegin kennt zwar ein --list, bringt aber beim
Schreiben auf die SD immer eine Fehlermeldung:
Error reading file: 87 Falscher Parameter
19+1 records in
19+1 records out

unter Ubuntu war dann alles kein Problem

Peter

[Joe G. (feinmechaniker)]

Ich kann nur wiederholen; Es wird mal Zeit für eine ordentliche 
Dokumentation. Macht Mühe, aber erleichtert ungemein den Nachbau und 
verhindert sinnloses doppelt, dreifach,..., probieren. Mein Vorschlag: 
Einer nimmt sich dem Thema an, "Wie bringe ich ein CP/M System auf die 
SD-Card - eine Anleitung Step by Step". Da unter Windows alles recht 
bes**eiden geht, gleich eine Anleitung für Linux (Live CD).
Joe

[Peter S. (petersieg)]

Ich habe den Artikel mal mit entsprechenden Informationen angereichert..
In die grundsätzliche Bedienung eines Partitionierungstools muß man sich
aber selber und unabhängig einarbeiten!!

Ich hänge hier auch mal ein BDS-C Sourcearchive an, in dem Spiele und 
unter
anderem auch Pacman enthalten ist.. ich habe z.Z wenig Zeit.. evtl. hat 
ja mal jemand Zeit und Lust, das auch nach VT100 und unser System 
umzusetzen..
sollten nur 3-4 Routinen sein (ClrSCR, PosXY,..)..

Peter

[Leo C. (rapid)]

Peter Sieg schrieb:
> sollten nur 3-4 Routinen sein (ClrSCR, PosXY,..)..

Ich habe mal reingeschaut, weil ich auch dachte, daß das ganz schnell 
gemacht wäre. Leider gings nicht ganz so schnell, weil das Programm 
direkt auf den UART-Port zugreift. Das wurde bisher von unserem System 
noch nicht unterstützt. Wahrscheinlich hätte man den Pacman auch an die 
BIOS Console-I/O anpassen können, aber ich habe es jetzt mal anders 
herum gemacht.

Die Cursor-Steuerung habe ich mal auf die Tasten 2,4,6,8 (Ziffernblock) 
gelegt.

Damit der Pacman aus dem Anhang läuft, muß man den ATmega updaten:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/avrcpm/avr/

[Peter S. (petersieg)]

@Leo C. Super! Probiere ich am WE direkt mal aus..

Danke! Peter

[Peter S. (petersieg)]

Jup. Pacman in aktion ;-)

Peter

[Peter Z. (flexopete)]

Moin,

welchen Assembler ist sinnvoll, um die AVR asm Dateien
unter Windows zu übersetzen?

Gruß
Peter

[Ronny M. (hobby-coder)]

hallo ihr,

ist evtl. noch ein bausatz zu haben? wenn ja, was kostet er?

[Leo C. (rapid)]

Peter Zabel schrieb:
> welchen Assembler ist sinnvoll, um die AVR asm Dateien
> unter Windows zu übersetzen?

avrasm2.exe aus dem AVR Studio.
Gibts denn noch andere?

[h3aau (Gast)]

@Peter
Schau da mal rein.

http://www.steinhartw.de/avr-studio-projekt/studio_projekt.htm

[Joe G. (feinmechaniker)]

Ronny Minow schrieb:
> hallo ihr,
>
> ist evtl. noch ein bausatz zu haben? wenn ja, was kostet er?

Sorry zu spät, alle Bausätze sind schon vergeben.
Joe

[Peter S. (petersieg)]

Ronny Minow schrieb:
> ist evtl. noch ein bausatz zu haben? wenn ja, was kostet er?

Falls kein Bausatz mehr 'übrig' sein sollte.. die 4-bit Version kann man 
sicher auch einfach auf Lochraster aufbauen.. ansonsten kann ich dir 
4-bit
als fertig aufgebaute Platine (3,3V Versorgung - ohne FT232) anbieten.
Bei Interesse E-Mail: peter (dot) sieg2 (at) gmx (dot) de

Peter

[Ronny M. (hobby-coder)]

Peter Sieg schrieb:
> Ronny Minow schrieb:
>> ist evtl. noch ein bausatz zu haben? wenn ja, was kostet er?
>
> Falls kein Bausatz mehr 'übrig' sein sollte.. die 4-bit Version kann man
> sicher auch einfach auf Lochraster aufbauen.. ansonsten kann ich dir
> 4-bit
> als fertig aufgebaute Platine (3,3V Versorgung - ohne FT232) anbieten.
> Bei Interesse E-Mail: peter (dot) sieg2 (at) gmx (dot) de
>
> Peter

wo finde ich den aktuellen schaltplan? ich habe hier 2 atmega32 frei. 
der source dürfte wohl leicht anpassbar sein. hat das evtl. schon jemand 
gemacht?

[Peter Sieg (Gast)]

Im Artikel:
http://www.mikrocontroller.net/articles/AVR_CP/M

findest du Schaltplan+Eagle Dateien für die 4-bit Version.

hier auch als Skizze:
http://avr.cwsurf.de/

Die 8-bit Version findest du sicher etwas weiter oben in diesem Thread..
den du ruhig auch mal durchlesen solltest.. ;-)

Peter

[Joe G. (feinmechaniker)]

Ronny Minow schrieb:
> wo finde ich den aktuellen schaltplan?

Hier ist der aktuelle Schaltplan der 8 Bit Version.

[Ronny M. (hobby-coder)]

hallo ihr,

ein großes danke an euch :) ich werde mir mal die 4bit version auf 
lochraster aufbauen.

[Peter S. (petersieg)]

Ronny Minow schrieb:
> ich werde mir mal die 4bit version auf
> lochraster aufbauen.

Na dann mal schon ein herzliches Willkommen im Club ;-)

Peter

[Peter Z. (flexopete)]

Moin,
habe gerade beide Platinen aufgebaut. Danke an Joe für seine
Arbeit mit der Platine, den Bauteilen und dem Versand.
Allerdings habe ich noch nicht rausfinden können, wie
die Versorgung ohne USB-Power, sprich Versorgung von der
VGA-Platine geht. 5V für den Controller, 3,3V für die SD.

Gruss
Peter

[Hans- w. S. (hschuetz)]

Hallo,
na zusammen hab ich die Platinen auch schon... aber leider nicht die 
Unterlagen. Welche Software passt nun auf den 168er?
Gruß
Hans- Werner

[Joe G. (feinmechaniker)]

Ich hatte drei Tage DSL Ausfall :-((
Zu euren Fragen:

@Peter1
Die RAM’s lassen sich wunderbar mit einer Heißluftpistole ablöten.

@Peter2
Variante 1 – Stromversorgung über VGA
1. Auf der VGA Platine natürlich den Gleichrichter und die beiden Regler 
(5V und 3.3V) bestücken.
2. Am Power Switch Pin1, Pin2 und Pin3 verbinden.
3. Am JP13 (VGA-Seite) sollten nun an Pin1 GND, an Pin2 5V, und an Pin3 
3.3V anliegen.
4. Auf der AVR-CP/M Platine JP7, Pin2 und Pin3 verbinden (3.3V von VGA)
Nun läuft der Controller auf der AVR CP/M und VGA Platine mit 5V und die 
SD mit 3.3V

Variante 2a – Stromversorgung über USB (5V für AVR 3.3V für SD)
1.  Auf der AVR-CP/M Platine JP1 Pin2 und Pin3 verbinden (5V über USB)
2.  Auf der VGA Platine JP11 Pin2  und Pin3 verbinden (3.3V über 
externen Regler auf VGA)
3.  Auf der ACR-CP/M Platine JP7 Pin2 und Pin3 verbinden (3.3V auf SD).

Variante 2b – Stromversorgung über USB (3.3V für CP/M AVR  und SD)
1. Auf der AVR-CP/M Platine JP1 Pin1 und Pin2 verbinden (3.3V über 
FT232)

@Hans W.
Anbei die Schaltungsunterlagen als PDF und als EAGLE.
Die Software liegt bei Leo C. auf SVN. Ich selber habe die 8 Bit Version 
noch nicht für den ATMEGA 168 übersetzt, könnten Peter oder Leo sicher 
tun. Der VGA Software wende ich mich nach der Bestückung zu.

Kritik, Fehler in Schaltung und/oder Layout nehme ich natürlich auch 
entgegen.
Joe

[Peter S. (petersieg)]

Joe G. schrieb:
> Die RAM’s lassen sich wunderbar mit einer Heißluftpistole ablöten.

Jup.. schön wenn man eine hätte.. :-(

Peter

[h3aau (Gast)]

Moin moin,

Das ist noch ein fehler im Layout.
Der Pin14 des FT232RL muus nicht mit 10K an GND sondern an VCC.
In der Defaultversion ist das die PWREN# Funktion.
Ansonsten ist es an den DRAM arg eng zu löten. Die Durchkontaktiereungen 
sind da etwas im weg. Sonst sind Platinen schon klasse für den Preis.

[Joe G. (feinmechaniker)]

h3aau schrieb:
> Das ist noch ein fehler im Layout.
> Der Pin14 des FT232RL muus nicht mit 10K an GND sondern an VCC.

In der Tat! Ich ändere es in Schaltung und Layout. Für die jetzige 
Funktion sollte es aber keine Auswirkungen haben, da die 
Powerumschaltung per FET nicht genutzt wird.

[Peter Z. (flexopete)]

Moin,

ich habe jetzt eine Verbindung zum Terminal, allerdings
bekomme ich folgende Meldung:

CPM on an AVR, v1.0
0F<00@FFFFM: fill...wait...reread...00<01@0100
Initing mmc...
CP/M partition at: 061, size: 993537KB.
Partinit done.
Ok, CPU is live!

  H  C  A =00 BC =0000 DE =0000 HL =0000 SP =0000 PC =2000       30 01 
12 Invali
d opcode!

DRAM Problem?

Gruss
Peter

[Joe G. (feinmechaniker)]

Der nächste Schritt wäre ipl.bin ab Adresse 2000 zu starten. Dazu sollte 
der Code vorher korrekt von der MMC geladen sein (mal MMC Debug zur 
Kontrolle einschalten). Der Opcode 30 01 12 sieht nicht wie der Start 
von ipl.bin aus.
Joe

[Peter Z. (flexopete)]

moin Joe,

die cpm.bin ist aus dem Artikel.
Ich werde mal MMC Debug einschalten.
Zum Speichertest: Habe mal die Terminalausgabe mit
Hterm in hex mitgeschnitten. Bit0 ist 0, wenn es 1 sein
soll und 0 wenn es 1 sein soll. Die DRAMs sind
GM71C17400AJ6. Bei 20MHz gleiches Problem. Kann
es ein Timingproblem sein?

Gruss
Peter

[Peter Z. (flexopete)]

Moin,

so sieht die Ausgabe von MMC-Debug aus:

Initing mmc...
mmcInit
mmcCMD: 00 00000000 .. 95 CMDRes: 01
mmcCMD: 08 000001AA .. 87 CMDRes: 05
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 00000000 .. 01 CMDRes: 
01
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 00000000 .. 01 CMDRes: 
00
mmcCMD: 10 00000200 .. 01 CMDRes: 00
 CT: 02 InitRes: 00
mmcCMD: 11 00000000 .. 01 CMDRes: 00
CP/M partition at: 061, size: 993537KB.
Partinit done.
mmcCMD: 11 00007A00 .. 01 CMDRes: 00
Ok, CPU is live!

        A =00 BC =0000 DE =0000 HL =0000 SP =0000 PC =2000       30 01 
12 Invalid opcode!

Gruss
Peter

[Leo C. (rapid)]

Peter Zabel schrieb:
> so sieht die Ausgabe von MMC-Debug aus:

MMC ist hier wahrscheinlich uninteressant.

>         A =00 BC =0000 DE =0000 HL =0000 SP =0000 PC =2000       30 01
> 12 Invalid opcode!

Nach laden des ipl sollte ab 2000 die Bytefolge 31 00 10 stehen (alles 
Hex).
Bei Dir steht 30 01 und evtl. 12. Und 30 ist für den 8080 ein ungültiger 
Opcode. Das passt gut zu Deinen Speichertestergebnissen. Wie Deine 
Hardware es allerdings fertig bringt, ein Bit zwischen Lesen und 
Schreiben zu invertieren, ist mir ein Rätsel. ;-)

[Peter Z. (flexopete)]

Moin,

habe die Ausgabe vom Speichertest weiter untersucht.
Es ist nicht nur D0 betroffen, sondern auch D1, D2, D3.
Abhängig von der Adresse. Hat jemand ein funktionierendes
168er hex-file, 20 oder 25MHz zum testen für mich?
Meine fuses sind lf=0xE0, hf=0xDC.

Gruss
Peter

[Frank Z. (fzoll)]

Halloe.

Ich schlage mich leider immer noch mit der Partinionierung meiner 
SD-Card und dem aufbringen der Images rum. Die Idee, das ganze auf 
eigene Partinionen zu packen klingt zwar recht nett, macht aber einen 
riesenumstand für alle Windows-User.

Ich habe letzte nach extra einen "alten" PC platt gemacht um Linux drauf 
zu spielen. Nun kämpfe ich mit der Hardwareerkennung von Linux. Seitdem 
ich die SD-Card unter Linux neu partinioniert habe, wird sie beim 
einstecken nicht mehr gefunden. Ich komme praktisch nicht mehr drauf. 
Defekt ist die Karte wohl noch nicht, da Windows die eine FAT16 
Partition die ich gelassen habe noch erkennt und nutzen kann.

Im moment überlege ich gerade, ob man das ganze nicht evtl. auf Dateien 
in einem "sticknormalen" FAT16 umstellen könnte. Ich denke darüber nach, 
die mit dem CPM-Tools angelegten images einfach mit einem bestimmten 
Namen in das Root-Verzeichniss einer FAT16-Partition zu packen. Sowas 
wie "diska.img", "diskb.img" .. usw. Und statt die Sektoren in den 
Partitionen direkt anzusprechen, könnte man dann auf den Dateien 
"rumrödeln".

Sollte ich die nächten Wochen mal Zeit dazu haben, werde ich mal 
versuchen die bekannten FAT16-Treiber mit in den Source des CP/M 
Projekts einzubinden. Leider ist meine Freizeit jedoch sehr beschränkt, 
so das das bei mir ewig dauern könnte.

Freundliche Grüße
Frank

[Leo C. (rapid)]

Peter Zabel schrieb:
> habe die Ausgabe vom Speichertest weiter untersucht.
> Es ist nicht nur D0 betroffen, sondern auch D1, D2, D3.
> Abhängig von der Adresse.

Für mich sieht das nach einem Hardwarefehler aus.
Bitte Verdrahtung nochmal überprüfen.
Durchgang, Kurzschluß, A8-A10?
Hat Dein RAM evtl. doch eine A11?
Stromversorgung, Blockkondensatoren, ...
Kannst Du das RAM (testweise) mit 5V betreiben (evtl. SD-Karte ziehen)?

> Hat jemand ein funktionierendes
> 168er hex-file, 20 oder 25MHz zum testen für mich?
> Meine fuses sind lf=0xE0, hf=0xDC.

Andererseits:
Welche Hardware-/Softwarekombination hast Du überhaupt?
Software scheint ja die neueste aus dem "modules" Zweig zu sein. Die ist 
mit der 4-Bit Hardware nicht besonders gut getestet.

[Leo C. (rapid)]

Frank Zoll schrieb:
> Halloe.
>
> Ich schlage mich leider immer noch mit der Partinionierung meiner
> SD-Card und dem aufbringen der Images rum. Die Idee, das ganze auf
> eigene Partinionen zu packen klingt zwar recht nett, macht aber einen
> riesenumstand für alle Windows-User.

Für alle anderen aber nicht. :)

> Ich habe letzte nach extra einen "alten" PC platt gemacht um Linux drauf
> zu spielen.

Einige hier kommen mit einer Linux Live-CD ganz gut zurecht.

> Nun kämpfe ich mit der Hardwareerkennung von Linux. Seitdem
> ich die SD-Card unter Linux neu partinioniert habe, wird sie beim
> einstecken nicht mehr gefunden. Ich komme praktisch nicht mehr drauf.

Gibt es irgendwelche Logeinträge?
(z.B. in '/var/log/syslog' oder '/var/log/kern.log')

> Defekt ist die Karte wohl noch nicht, da Windows die eine FAT16
> Partition die ich gelassen habe noch erkennt und nutzen kann.
>
> Im moment überlege ich gerade, ob man das ganze nicht evtl. auf Dateien
> in einem "sticknormalen" FAT16 umstellen könnte. Ich denke darüber nach,
> die mit dem CPM-Tools angelegten images einfach mit einem bestimmten
> Namen in das Root-Verzeichniss einer FAT16-Partition zu packen. Sowas
> wie "diska.img", "diskb.img" .. usw. Und statt die Sektoren in den
> Partitionen direkt anzusprechen, könnte man dann auf den Dateien
> "rumrödeln".

Ja, das steht auch auf meiner todo-Liste. Aber ganz tief unten.
In´s 8K ROM paßt zwar kein FAT-Treiber mehr, aber das macht ja nichts.

> Sollte ich die nächten Wochen mal Zeit dazu haben, werde ich mal
> versuchen die bekannten FAT16-Treiber mit in den Source des CP/M
> Projekts einzubinden. Leider ist meine Freizeit jedoch sehr beschränkt,
> so das das bei mir ewig dauern könnte.

Dann wünsche ich Dir (und uns) mal eine große Portion Freizeit. :)

Man kann auch immer noch auf Partitionierung verzichten, und ein 
CP/M-Image direkt an den Anfang einer Speicherkarte schreiben. Wie das 
unter Windows geht, wissen die Experten hier.

[Peter Z. (flexopete)]

Moin,

Hardware ist die neue 8-Bit Platine.
Das DRAM hat A0 - A10.
Ich habe keine Verbindung zwischen A8,A9,A10 und
D0 - D4. Der 168er läuft mit 5V, die SD mit 3,3V.
Die Software habe ich am 31.08. runtergeladen.
Mein List-File sagt:

Including file 'C:\Programme\Atmel\AVR 
Tools\AvrAssembler2\Appnotes\m168def.inc'
Including file 'D:\AVR_CPM-AVR\avr\config.inc'
Including file 'D:\AVR_CPM-AVR\avr\macros.inc'
Including file 'D:\AVR_CPM-AVR\avr\dram-8bit.inc'
Including file 'D:\AVR_CPM-AVR\avr\init.asm'
Including file 'D:\AVR_CPM-AVR\avr\mmc.asm'
Including file 'D:\AVR_CPM-AVR\avr\sw-uart.asm'
Including file 'D:\AVR_CPM-AVR\avr\dram-8bit.asm'
Including file 'D:\AVR_CPM-AVR\avr\remainders.asm'
Including file 'D:\AVR_CPM-AVR\avr\8080int-jmp.asm'

Gruss
Peter

[Leo C. (rapid)]

Peter Zabel schrieb:
> Moin,
>
> Hardware ist die neue 8-Bit Platine.
> Das DRAM hat A0 - A10.
> Ich habe keine Verbindung zwischen A8,A9,A10 und
> D0 - D4. Der 168er läuft mit 5V, die SD mit 3,3V.

Ich habe den letzten, von Joe als pdf geposteten Schaltplan mit meinem 
Aufbau verglichen. Ich habe keinen Unterschied gefunden. Das Layout 
sollte mit diesem Plan ja übereinstimmen.

> Die Software habe ich am 31.08. runtergeladen.

Danach gibt es bisher nur Änderungen bei der mmc-Fehlerbehandlung. Die 
Software läuft bei mit mit Mega8 und Mega328.

Läuft die Platine denn sonst schon bei jemandem? Joe?

[Peter Z. (flexopete)]

Mit "keine Verbindung" meine ich keinen Kurzschluss
zwischen A8,A9,A10 und D0 - D3.

Peter

[Frank Z. (fzoll)]

Leo C. schrieb:
>> Nun kämpfe ich mit der Hardwareerkennung von Linux. Seitdem
>
>> ich die SD-Card unter Linux neu partinioniert habe, wird sie beim
>
>> einstecken nicht mehr gefunden. Ich komme praktisch nicht mehr drauf.
>
>
>
> Gibt es irgendwelche Logeinträge?
>
> (z.B. in '/var/log/syslog' oder '/var/log/kern.log')

Ja, zu meinem leidwesen gibt es da welche die nicht gut klingen.

Wenn ich die SD- Card einlege wird sie noch erkannt. Er listet die größe 
der Karte korrekt als 1GB Karte.
Danach zeigt der mir noch an, das es darauf 4 Partitionen gibt. (sdc: 
sdc1 sdc2 sdc3 sdc4). Bis hier hin scheint er noch zu kommen.

sd 2:0:0:1 [sdc] 1958912 512-byte logical blocks: (1.00 GB/956 MiB)
sd 2:0:0:1 [sdc] Assuming drive cache: write through
sd 2:0:0:1 [sdc] Assuming drive cache: write through
sdc: sdc1 sdc2 sdc3 sdc4

Kurz darauf (ca. 2 Secunden abstand) kommt die Meldung:

usb 1-3: reset high speed USB device using ehci_hcd and address 2.

Gefolgt von:

sd 2:0:0:1 [sdc] Device not ready
sd 2:0:0:1 [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 2:0:0:1 [sdc] Sense Key : Not Ready [current]
sd 2:0:0:1 [sdc] Add. Sende: Medium not present
end_request: I/O error, dev sdc, sector 1958784
Buffer I/O error on device sdc, logical block 244848
sd 2:0:0:1 [sdc] Device not ready
sd 2:0:0:1 [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 2:0:0:1 [sdc] Sense Key : Not Ready [current]
sd 2:0:0:1 [sdc] Add. Sende: Medium not present
end_request: I/O error, dev sdc, sector 1958784
Buffer I/O error on device sdc, logical block 244848
sdc: detected capacity change from 1002962944 to 0

Danach bricht er den Versuch ab die Karte weiter an zu sprechen.

Habt ihr eine Idee, wie man die SD- Card unter Linux ( Suse 11.2 ) auf 
einem alten AMD64 Shuttle PC wieder ans rennen bringen könnte ?

Unter WindowsXP läuft die Karte problemlos. Nur Linux zickt da rum.

Grüße
Frank

[Frank Z. (fzoll)]

Könnt ihr mal einen Blick darauf werfen ?

Meine SD-Card konnte ich mitlerweile Partitionieren und mit den Images 
befüllen. Leider klappt das Booten aber noch nicht.
Für mich sieht es so aus als ob die Karte die ersten Kommandos nocht 
verarbeitet. Erst wenn versucht wird den ersten Sektor zu laden,
scheint die Karte nicht zu antworten.
Was meint ihr ?

CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
mmcInit SPI_CLK_SLOW
mmcCMD: 00 00000000 .. 95 CMDRes: 01
mmcCMD: 08 000001AA .. 87 CMDRes: 01
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 40000000 .. 01 CMDRes: 00
mmcCMD: 3A 00000000 .. 01 CMDRes: 00
 CT: 04 InitRes: 00 SPI_DISABLE
mmcRdSect SPI_CLK_FAST
mmcCMD: 11 00000000 .. 01 CMDRes: 00 SPI_DISABLE RdSectRes: 01 No bootable CP/M
disk found! Please change MMC/SD-Card.

Grüße
Frank

[Peter Z. (flexopete)]

Moin,

bei mir kommt folgende Fehlermeldung:

CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
mmcInit
mmcCMD: 00 00000000 .. 95 CMDRes: 01
mmcCMD: 08 000001AA .. 87 CMDRes: 05
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 00000000 .. 01 CMDRes: 
01
mmcCMD: 37 00000000 .. 01 CMDRes: 01 mmcCMD: 29 00000000 .. 01 CMDRes: 
00
mmcCMD: 10 00000200 .. 01 CMDRes: 00
 CT: 02 InitRes: 00
mmcCMD: 11 00000000 .. 01 CMDRes: 00
CP/M partition at: 061, size: 993537KB.
Partinit done.
mmcCMD: 11 00007A00 .. 01 CMDRes: 00
Ok, CPU is live!
ipl
DISK I/O: Invalid Function code: 01

Demnach müsste IPL schon etwas geladen haben.
Nur, was bedeutet diese Fehlermeldung?

Gruss
Peter

[Leo C. (rapid)]

Frank Zoll schrieb:

>  CT: 04 InitRes: 00 SPI_DISABLE

Karte ließ sich fehlerfrei initialisieren. Eine "SDC V2" Karte wurde 
erkannt.

> mmcRdSect SPI_CLK_FAST
> mmcCMD: 11 00000000 .. 01 CMDRes: 00 SPI_DISABLE RdSectRes: 01
          -- --------               --                        --
           1        2                3                         4

1, 2:  Befehl "Read Single Block", Sector 0 wird an Karte gesendet.
   3:  Befehl wurde von der Karte aktzeptiert.
   4:  Karte hat innerhalb des Timeouts kein gültiges
       'Data Token' (0xFE) gesendet.

Leider sieht man hier nicht, ob die Karte garnichts mehr gesendet hat, 
oder ein Fehlertoken.

Du könntest mal MMC_DEBUG auf 3 setzen. Villeicht kommt man dann 
dahinter.

[Leo C. (rapid)]

Peter Zabel schrieb:

Funktioniert der RAM-Test bei Dir inzwischen fehlerfrei?
Wenn nicht, kannst Du den Rest hier vergessen.

> CP/M partition at: 061, size: 993537KB.
> Partinit done.
> mmcCMD: 11 00007A00 .. 01 CMDRes: 00
> Ok, CPU is live!
> ipl
> DISK I/O: Invalid Function code: 01
>
> Demnach müsste IPL schon etwas geladen haben.

Das kann man so nicht sagen. Der ipl wird ohne Fehler von der Karte 
geladen. Ob er danach korrekt im RAM steht, wissen wir nicht.

> Nur, was bedeutet diese Fehlermeldung?

Gültige Codes wären diese hier:

  .equ  READ_FUNC  = 7
  .equ  WRITE_FUNC = 6
  .equ  BOOT_FUNC  = 5
  .equ  HOME_FUNC  = 4

Entweder läuft Dein IPL ins Nirwana (RAM-Fehler), oder IPL und BIOS 
passen nicht zu Deiner AVR Programmversion. Letzteres müßte nicht 
unbedingt an Dir liegen, da ich im SVN einiges an Chaos habe. Ich muß 
mal dringend aufräumen.

[Peter Z. (flexopete)]

Moin Leo,

ich habe auf LR ein 2.tes System aufgebaut. Das hat keine
Fehlermeldungen beim RAM-Test. Hast Du passende Dateien
für mich? Wäre doch schön die CP/M 2.2 Meldung auf dem
Terminal zu sehen.

Gruss
Peter

[Frank Z. (fzoll)]

Hm komisch. Ich habe die Debugmeldungen mal umgestellt.
Es sieht so aus, als ob von der Karte immer nur High- Pegel zurück 
gemeldet werden. In der Debug ausgabe steht bei allen Commandos FF. Ich 
werde wohl mal schauen müssen, ob ich da noch irgendwo eine von diesen 
viesen ungewollten Lötbrücken habe.

mmcInit SPI_CLK_SLOW <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
mmcCMD: 00 00000000 <FF <FF <FF >40 .. 95>95 <FF <01  CMDRes: 01
mmcCMD: 08 000001AA <FF <FF <FF >48 .. 87>87 <FF <01  CMDRes: 01 <00 <00 <01 <AA

mmcCMD: 37 00000000 <FF <FF <FF >77 .. 01>01 <FF <01  CMDRes: 01 mmcCMD: 29 4000
0000 <FF <FF <FF >69 .. 01>01 <FF <00  CMDRes: 00
mmcCMD: 3A 00000000 <FF <FF <FF >7A .. 01>01 <FF <00  CMDRes: 00 <80 <FF <80 <00
 <FF
 CT: 04 InitRes: 00 SPI_DISABLE
mmcRdSect SPI_CLK_FAST
mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00  CMDRes: 00 <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
 <FF <FF <FF <FF SPI_DISABLE RdSectRes: 01 No bootable CP/M disk found! Please c
hange MMC/SD-Card.

PS, die Karte ist noch nicht hin, kann sie unter WinXP immer noch lesen 
und beschreiben.

Grüße
Frank

[Leo C. (rapid)]

Frank Zoll schrieb:
> Es sieht so aus, als ob von der Karte immer nur High- Pegel zurück
> gemeldet werden.

Nicht immer, nur meistens. Das ist aber normal. Wenn die Karte nichts zu 
senden hat, ist die Data Out Leitung eben auf high.

> In der Debug ausgabe steht bei allen Commandos FF.

Siehe oben. Es wird aber auch immer noch nicht alles angezeigt.

> Ich
> werde wohl mal schauen müssen, ob ich da noch irgendwo eine von diesen
> viesen ungewollten Lötbrücken habe.

Glaube ich nicht.

> mmcCMD: 00 00000000 <FF <FF <FF >40 .. 95>95 <FF <01  CMDRes: 01
                                                **  **
Hier sendet die Karte zuerst FF, dann 01.

> mmcCMD: 11 00000000 <FF <FF <FF >51 .. 01>01 <FF <00  CMDRes: 00 <FF <FF
                                                **  **
Auf den Befehl antortet die Karte FF, 00.

> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF <FF
> <FF <FF
>  <FF <FF <FF <FF SPI_DISABLE RdSectRes: 01 No bootable CP/M disk found!

Hier scheint aber wirklich nichts mehr von der Karte zu kommen.
  --> Timeout.

Vielleicht ist die Wartezeit zu kurz. Ich werde mir das nachher nochmal 
genauer anschauen.

[Leo C. (rapid)]

Peter Zabel schrieb:
> ich habe auf LR ein 2.tes System aufgebaut. Das hat keine
> Fehlermeldungen beim RAM-Test.

Gut.

> Hast Du passende Dateien
> für mich? Wäre doch schön die CP/M 2.2 Meldung auf dem
> Terminal zu sehen.

Im Anhang ist mal ein komplettes System mit ipl, ccp, bdos und bios.
Das kannst Du mit dd auf den Anfang der CP/M-Partition kopieren.

[Peter Z. (flexopete)]

Moin Leo,

ok, das war es. Vielen Dank für die passende cpmsys.bin.
Passte wohl vorher nicht so zusammen. Werde mal anfangen,
Software draufzupacken.

Gruss
Peter

[Ronny M. (hobby-coder)]

hallo ihr,

ich habe die lochraster version weitgehend aufgebaut. meine ram chips, 
von meinen edo ram's, scheinen aber ungeeignet zu sein. laut den mir 
vorliegenden schaltplänen kommen die signale an anderen pins herein. 
ausserdem gehen die leiterbahnen über einen kleinen chip auf der platine 
(signal koverter...?).

ob ein direkter anschluss möglich ist, oder ich diesen winzigen smd chip 
(16 kontakte) brauche, weis ich nicht. daher einfach die frage:

wo bekomme ich passende ram chips her? idealer weise über reicheld und 
im dip gehäuse. ausser, man kann diese auf lochraster gut löten, ohne 
tiefergehende smd lötkenntnisse zu besitzen.

---

[edit] pinzahl korrigiert

[Hans- w. S. (hschuetz)]

Hallo,
hat einer schon die neue Platine in Gange? irgendwie finde ich nicht die 
richtige Software. Das mit dem SVN ist der letzte Schrott, Dateien 
lassen sich da nicht wirklich herunterladen.....
Gruß
Hans- Werner

[Leo C. (rapid)]

Hans- w. Schütz schrieb:
> richtige Software. Das mit dem SVN ist der letzte Schrott, Dateien

Kann sein ;)

> lassen sich da nicht wirklich herunterladen.....

Natürlich lassen sie sich...
Was genau funktioniert denn bei Dir nicht?

Versuchs mal hier:
http://cloudbase.homelinux.net/viewvc/avr-cpm/branches/modules/avrcpm/

Und dann oben rechts auf den Knopf "Download Tarball" klicken.

[Leo C. (rapid)]

Ronny Minow schrieb:
> ich habe die lochraster version weitgehend aufgebaut. meine ram chips,
> von meinen edo ram's, scheinen aber ungeeignet zu sein. laut den mir
> vorliegenden schaltplänen kommen die signale an anderen pins herein.

Ich habs noch nicht getestet, aber prinzipiell müßten EDO's eigentlich 
auch gehen.
Wie heißen Deine Chips denn genau?

> ausserdem gehen die leiterbahnen über einen kleinen chip auf der platine
> (signal koverter...?).

Das sind wahrscheinlich Serienwiderstände.


> ob ein direkter anschluss möglich ist, oder ich diesen winzigen smd chip
> (16 kontakte) brauche, weis ich nicht. daher einfach die frage:

Kann man weglassen.

> wo bekomme ich passende ram chips her? idealer weise über reicheld und
> im dip gehäuse. ausser, man kann diese auf lochraster gut löten, ohne
> tiefergehende smd lötkenntnisse zu besitzen.

Raketenwissenschaft ist's keine. Etwas Übung ist allerdings von Vorteil. 
Dann kann mit die SOJ- und TSOP-Gehäuse ganz gut auf Lochraster löten, 
wenn man die Pads vorher mit einem Messer in zwei Hälften teilt.

Hier hatte ich schon mal ein Bild gepostet:
Beitrag "Re: CP/M auf ATmega88"

[Frank Z. (fzoll)]

Halloe.

Also ich bin einen kleinen Schritt weiter gekommen. Ich habe einfach 
eine andere SD-Card genommen. Nun hänge ich am nächsten Schritt fest.

Dies sind die letzten Zeilen der Debug-Ausgabe:

mmcCMD: 11 35A56600 .. 01 CMDRes: 00
Ok, CPU is live!

 ZHPNC  A =DE BC =0000 DE =0000 HL =0000 SP =FFEF PC =2E32       CB CB CB Invali
d opcode!

Wenn ich das richtig interpretiere, hat das lesen des ersten Sektors der 
Partition noch geklappt. Aber scheinbar stehen im RAM immer noch die 
Code's CBCBCB vom RamTest. Scheinbar sind die Daten aus dem Sektor dort 
nicht angekommen. Oder ?

Grüße
Frank

p.s. Wer meint das seine SD-Card auch nicht tut, der möge mal auf den 
Hersteller schauen. Die Karten von "PLATINUM" machen wohl ziemliche 
Probleme. Nun habe ich eine 1GB SD-Card von Verbatim am laufen. Die 1GB 
Card von Platinum will mit dieser Hardwareversion nicht ans laufen 
kommen.

[Frank Z. (fzoll)]

Mit der letzten hier geposteten Version cmpsys.bin von Leo bekomme ich 
die folgende Fehlermeldung:

mmcCMD: 11 35A56600 .. 01 CMDRes: 00
Ok, CPU is live!

 ZHPNC  A =DE BC =0000 DE =0000 HL =0000 SP =FFEF PC =2000       30 0D 1A Invali
d opcode!

Scheint noch net alles kapuut zu sein. Ist alles nur recht tricky.
Frank

[Leo C. (rapid)]

Frank Zoll schrieb:
> Halloe.
>
> Also ich bin einen kleinen Schritt weiter gekommen. Ich habe einfach
> eine andere SD-Card genommen. Nun hänge ich am nächsten Schritt fest.
>
> Dies sind die letzten Zeilen der Debug-Ausgabe:
>

> mmcCMD: 11 35A56600 .. 01 CMDRes: 00
> Ok, CPU is live!
> 
>  ZHPNC  A =DE BC =0000 DE =0000 HL =0000 SP =FFEF PC =2E32       CB CB
> CB Invalid opcode!

> Wenn ich das richtig interpretiere, hat das lesen des ersten Sektors der
> Partition noch geklappt. Aber scheinbar stehen im RAM immer noch die
> Code's CBCBCB vom RamTest. Scheinbar sind die Daten aus dem Sektor dort
> nicht angekommen. Oder ?

Der IPL wird auf 2000 bis 207F geladen. CB auf 2E32 ist also völlig in 
Ordnung. ;-)
Warum der Prozessor dort hin springt kann wieder 2 Gründe haben:
1. RAM fehlerhaft. (unwahrschinlich, wenn RAM-Test ok)
2. IPL und/oder Rest auf den "Systemspuren" schrottig.

Vorschlag: System von obigem Artikel testen:
Beitrag "Re: CP/M auf ATmega88"

---

Gerade wollte ich auf "Absenden" drücken und sehe Deinen neuen Artikel:
Frank Zoll schrieb:
>  ZHPNC  A =DE BC =0000 DE =0000 HL =0000 SP =FFEF PC =2000       30 0D
> 1A Invalid opcode!

Das sieht dann aber doch nach einem Hardwarefehler aus.
Statt "30 0D 1A" sollte da "31 00 10" stehen.

[Leo C. (rapid)]

Frank Zoll schrieb:

> mmcCMD: 11 35A56600 .. 01 CMDRes: 00
             ********

Diese Zahl erscheint mir reichlich groß. Kannst Du mal die vollständigen 
Bootmeldungen posten (Mit oder ohne MMC_DEBUG)?

Deine Partitionstabelle würde mich auch interessieren. Unter Linux wäre 
das:

# fdisk -cul /dev/xxx

Oder ein Dump des ersten Sektors:

# dd if=/dev/xxx of=part-dump.bin bs=512 count=1

[Frank Z. (fzoll)]

Juhu, freu es tut zum ersten mal :-)

Als letzten Fehler war eine der Adressleitungen nicht richtig 
angeschlossen. Nun läufts mit der neuen Platine auch einwandfrei.
Als Prozessor habe ich den Atmega168 genommen. Sourcen stammen aus dem 
SVN. Habe es nun erfolgreich mit dem AVR Studio Compiliert und 
installiert bekommen. Habe mir einfach ein kleines neues Projekt 
angelegt, die Sourcen reingeworfen und die Config auf 8bit und 168er 
Atmega angepasst.
Als Betriebssystem auf der SD-Card hab ich die oben als letztes gelinkte 
Version genommen.

CPM on an AVR, v1.0
Testing RAM: fill...wait...reread...
Initing mmc...
CP/M partition at: 1757875, size: 9765KB.
CP/M partition at: 1777406, size: 9765KB.
CP/M partition at: 1796937, size: 73464KB.
Partinit done.
Ok, CPU is live!

ipl
62k cp/m vers 2.2

A>dir
A: ASM      COM : DDT      COM : DUMP     COM : ED       COM
A: T        COM : TLOOP    COM : LOAD     COM : MBASIC   COM
A: 23       BAS : BAGELS   BAS : CHECKERS BAS : STARTREK BAS
A: TREKINST BAS : MASTRMND BAS : WEEKDAY  BAS : PIP      COM
A: STAT     COM : SUBMIT   COM : XSUB     COM : ZORK1    COM
A: ZORK1    DAT
A>

Vielen Dank für eure Hilfe.
Euer Frank

[Leo C. (rapid)]

Frank Zoll schrieb:
> Juhu, freu es tut zum ersten mal :-)

Herzlichen Glückwunsch und Willkommen im Club.

> angeschlossen. Nun läufts mit der neuen Platine auch einwandfrei.

Das ist ja mal 'ne Aussage.

> CP/M partition at: 1757875, size: 9765KB.
                     *******

Das sieht auch viel besser aus als 900032000 (= 0x35A56600).

> Vielen Dank für eure Hilfe.

Wir freuen uns jetzt auf den FAT16-Treiber. :-)

[Peter S. (petersieg)]

Hat jemand 4 Ramchips ***ausgelötet*** über?
Wollte mich die nächsten Tage mal an einen 8-bit Lochrasteraufbau 
wagen..
(Ich weiß, das 2 auch reichen.. aber bei smd + LR besser Reserve;
Und meine Platine habe ich an einen weiteren, neuen Mitstreiter 
abgetreten)

Peter

[Frank Z. (fzoll)]

Leo C. schrieb:
> Wir freuen uns jetzt auf den FAT16-Treiber. :-)

Hihi,

ich auch. Ich habe mir gestern Nacht schonmal ein wenig den Kopf darüber 
zerbrochen. Soweit ich das einschätze wird es möglich sein. Ich habe 
eine neue FAT16.asm Datei angelegt und schonmal angefangen die ersten 
FAT16 Implementierungen vorzubereiten.

Zum aktuellen Stand:
- Eine FAT16 Partition wird bereits erkannt.
- Der BootSektor der FAT16 Partition wird bereits erfolgreich gelesen.

Nächste Schritte:
- Finden und Auswerten des Root-Verzeichnisses.
- Zuordnung gefundener Images auf die bestehenden Laufwerke A: bis D:.
- Finderoutine für das Auffinden beliebieger Sektoren über die 
FAT-Einträge in den Image-Dateien
- Read/Write des gefundenen Sektors über die bestehenden MMC-Routinen 
anbinden.


Ich werde mit einem sehr stark eingeschränkten FAT16 Treiber die Sache 
wohl ans laufen bringen.

Folgende Eckdaten denke ich lassen sich erreichen:
- Es wird eine FAT16 Partition vorausgesetzt.
- In der FAT16 Partition wird es ein Paar Dateien geben, die die 
einzelnen CP/M Partitionen darstellen werden.
- Die Image- Dateien müssen im ROOT- Verzeichniss der FAT16 Partition 
angelegt werden.
- Die Image- Dateien werden sich nicht auf dem AVR-CP/M anlegen lassen. 
So spare ich mir die Implementierung von "create_file"- Funktionen. (Da 
sehr Umständlich)
- Die Namen für die Image- Dateien werden wir im Code fest hinterlegen.
- Die Größe der Image-Dateien kann nicht dynamisch geändert werden. Die 
Images müssen praktisch von anfang an die volle Größe einer CP/M - 
Partition abbilden.
- Die Performance wird gegenüber den direkten CP/M Partionen stark 
leiden. Bei jedem Sektorzugriff muss dieser erst umständlich in der 
jeweiligen Image-Datei gesucht werden. ( Juhu Retro like nix schnelle 
:-) )
- Schreiben und Lesen einzelner Sektoren der Image-Dateien wird 
funktionieren.
- Ich verwende den Pufferspeicherblock, der schon für das 
Lesen/Schreiben der CP/M Partitionen verwendet wird einfach wieder. Ich 
brauche ein paar zusätzliche Bytes, für die wichtigsten Variablen ausm 
FAT16 System. Ich werde mit den derzeit noch verbliebenen knapp 100 
Bytes SRAM eines 168AVR's wohl hinkommen. ( Ein paar Bytes werde ich 
noch überlassen :-) )
- Ich mache die FAT16 Implementierung speziel für dieses Projekt neu, um 
so viel Speicher und Resourcen wie nur irgend geht einzusparen.
- Ich versuche das ganze "unauffällig" in den bestehenden Code 
einzufügen. Am Ende wäre das Ziel das man gleichzeitig mit FAT16 und 
CP/M Partitionen arbeiten kann.

Grüße
Frank

[Hans- w. S. (hschuetz)]

Hallo,
heute bin ich endlich dazu gekommen die Software in den 168er zu 
flashen.
Hardware ist das neue Board. Leider hängt es schon beim reread des Ram:
CPM on an AVR, v1.0

01<38@0139M: fill...wait...reread...F0<00@0000
nach einem Reset:

CPM on an AVR, v1.0
Fô<83@0083M: fill...wait...reread...F0<00@0000

hat jemand eine Idee??
die vorderen Zeichen wechseln ständig???
Ram Fehler?
Gruß
Hans- Werner

[Detlev T. (detlevt)]

Hallo hschuetz,

leider kenne ich mich mit diesem Projekt nicht gut aus und weiß daher 
nicht, ob hier Interrupts verwendet werden.

Falls ja, stellt sich die Frage, ob die von dir genutzte Firmware an den 
168 angepasst wurde. Der reserviert nämlich doppelt so viel Speicher für 
jeden Vektor in der Tabelle. Trotz großer Ähnlichkeit wird eine 
atmega88-Version daher nicht ohne Änderung auf einem 168 laufen.

Gruß, DetlevT

[Ronny M. (hobby-coder)]

Leo C. schrieb:
> Ich habs noch nicht getestet, aber prinzipiell müßten EDO's eigentlich
> auch gehen.
> Wie heißen Deine Chips denn genau?

Ich habe in mein Archiv noch einmal nachgeschaut und Edo Ram Riegel mit 
folgenden Chips gefunden:

* MSC 9618 C USA - MT 4C4001JDJ - 6
* OKI - M5I4400C-60SJ - 53825229A9Z
* Samsung - 447Y - KM44C100CJ - 7
* IBM - 014400J1F - 60 50H6697 - IBM 9370 - 625110500 Q
* MSC 9638 C USA - MT 4C4007JDJ - 6

Ich habe einfach mal alle Ziffern auf den Chips abgetippt, da ich nicht 
weis, welche Ziffern entscheident sind...

[Leo C. (rapid)]

Ronny Minow schrieb:
> Ich habe in mein Archiv noch einmal nachgeschaut und Edo Ram Riegel mit
> folgenden Chips gefunden:

** MSC 9618 C USA - MT 4C4001JDJ - 6
  MT4C4001JDJ-6 - standard or self refresh -
  Micron Technology
http://www.alldatasheet.com/datasheet-pdf/pdf/75901/MICRON/MT4C4001JDJ-6.html

>* OKI - M5I4400C-60SJ - 53825229A9Z
  HM514400CL - 1,048,576-word X 4-bit Dynamic Random
  Access Memory - Hitachi Semiconductor
http://www.alldatasheet.com/datasheet-pdf/pdf/84404/HITACHI/HM514400CL.html

>* Samsung - 447Y - KM44C100CJ - 7
  KM44C1000D - 1M x 4Bit CMOS Dynamic RAM with
  Fast Page Mode - Samsung semiconductor
http://www.alldatasheet.com/datasheet-pdf/pdf/37282/SAMSUNG/KM44C1000D.html

>* IBM - 014400J1F - 60 50H6697 - IBM 9370 - 625110500 Q
http://www.idhw.com/textual/guide/noin_ram_chip_ibm.html

>* MSC 9638 C USA - MT 4C4007JDJ - 6
  MT4C4007J - 1 MEG x 4 DRAM 5V, EDO PAGE MODE,
  OPTIONAL SELF REFRESH - Micron Technology
http://www.alldatasheet.com/datasheet-pdf/pdf/120124/MICRON/MT4C4007J.html

Wenn ich's recht überblicke, sind die ersten 3 "Fast Page Mode" RAM's, 
also keine EDO's. Zum IBM habe ich auf die Schnelle kein Datenblatt 
gefunden.

Meiner Meinung nach müßten die alle funktionieren. Es sind aber alles 
1Mx4 Steine, und die haben leider eine andere Pinbelegung als die 4Mx4. 
Damit passen Sie leider nicht auf die neue Leiterplatte von Joe. Aber Du 
wolltest ja lochrastern...

[Leo C. (rapid)]

Detlev T. schrieb:
> leider kenne ich mich mit diesem Projekt nicht gut aus und weiß daher
> nicht, ob hier Interrupts verwendet werden.

Aber wenn Du nur 4 Artikel weiter nach oben geschaut hättest, hättest Du 
sehen können, daß gerade jemand mit Mega168 Erfolg gemeldet hat.

> Falls ja, stellt sich die Frage, ob die von dir genutzte Firmware an den
> 168 angepasst wurde. Der reserviert nämlich doppelt so viel Speicher für
> jeden Vektor in der Tabelle. Trotz großer Ähnlichkeit wird eine
> atmega88-Version daher nicht ohne Änderung auf einem 168 laufen.

Joe G. hat von Anfang an einen 168, und ich bastle mit einem Mega8 und 
einem Mega328 rum.