mengstr / cpm8266 Goto Github PK

In nosdk/nosdk8266.c the setting of the overclock bit got buggy after my hacking.

// *(volatile uint32_t *)(PERIPHS_DPORT_BASEADDR + (0x14 / 4)) |= 0x01;

"make full" build and upload the emulator but not the disks.
Boot sequence ends with "cpm8266 - Z80 Emulator and CP/M 2.2 system version 0.4"
Still I was not able to figure out how to recursively build and upload all the pieces.

Considering you may be the first project that dinked with it significantly, what changes did you need to make to nosdk8266? What changes would you recommend? Would you mind making a pull request?

Sort and tidy up the contents of the disk images. Add some good-to-have utilities and classic applications.

Create a FILES.TXT in the A: drive describing what's on the drives.

[CC] main.c
In file included from main.c:3:0:
espincludes.h:39:6: error: conflicting types for 'ets_isr_attach'
void ets_isr_attach(int intr, void *handler, void *arg);
^
In file included from /home/aldo/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/include/os_type.h:28:0,
from main.c:2:
/home/aldo/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/include/ets_sys.h:67:6: note: previous declaration of 'ets_isr_attach' was here
void ets_isr_attach(int i, ets_isr_t func, void *arg);
^
Makefile:109: set di istruzioni per l'obiettivo "main.o" non riuscito
make: *** [main.o] Errore 1

maybe there was an update in the sdk??

The Intel Hex upload fails to what seems like lost characters even at 9600 baud. This probably will be fixed by using an interrupt-driven buffered RX module.

Had some problems uploading so I want to share how i solved them.
In /cpm8266/code/Makefile there are the upload parameters. i've changed them to match the one used with Arduino IDE:

FLASHPARAM = --flash_freq 40m --flash_mode qio
FLASHBAUD = 115200

So if the upload fails you know what to check

For instance when doing a A:DUMP ED.COM

Are there specific version requirements for esp-open-sdk? I just tried to build cpm8266 with the current versions of it and esp-open-sdk, and the cpm8266 Makefile pukes immediately:

In file included from main.c:3:0:
espincludes.h:39:6: error: conflicting types for 'ets_isr_attach'
 void ets_isr_attach(int intr, void *handler, void *arg);
      ^
In file included from /home/howie/Work/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/include/os_type.h:28:0,
                 from main.c:2:
/home/howie/Work/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr/include/ets_sys.h:67:6: note: previous declaration of 'ets_isr_attach' was here
 void ets_isr_attach(int i, ets_isr_t func, void *arg);
      ^
Makefile:109: recipe for target 'main.o' failed
make: *** [main.o] Error 1

Commenting line 39 of espincludes.h resolves it, as your prototype doesn't match the one the library provides.

Possibly the procTask-callback is not called often enough.

The version number does not change on every commit.
For tracking bugs knowing the commit exactly might be helpful.
Would adding something like the output of...

$ git describe --always 
eb5af62

...to the version string cause problems?

Do you guys have room for a textbuffer? If so, I may be inclined to write something that can output that textbuffer to an NTSC connection on the I2S pin.

Today it's hardcoded deep inside the code..

The red LED o the NODEMCU should be lit as long as the disk buffer isn't flushed to disk as a warning to the user to not reboot the esp.

This will also show disk write activity

Would it be possible to get a pre-compiled binary of the WiFi enabled version, as is supplied for the Serial version. I understand it limits the ram available in BASIC to 5K, but for fun and easier experimentation this would suffice. If WiFi enabled, I can just leave it on, connecting as needed.
It's a great emulator, and I've had a lot of fun with it. Even got the original Adventure copied over and working. So, either way, excellent job, works really well. Thank You.

I had to install the package vim-common (on Debian8/AMD64) to satisfy the Makefile's wish to find xxd.

$ apt-file find bin/xxd
vim-common: /usr/bin/xxd
vim-dbg: /usr/lib/debug/usr/bin/xxd
xxdiff: /usr/bin/xxdiff

...there seems not to be a different source for xxd... :-/

All make targets except the ones for uploading:

$ git describe --always 
6a367a5
$ make clean bins disks systemdiskA
[CC] main.c
[CC] machine.c
[CC] uart.c
[CC] conio.c
[CC] flash.c
[CC] monitor.c
[CC] utils.c
[CC] gpio16.c
[CC] z80/z80emu.c
[AS] nosdk/startup.S
[CC] nosdk/nosdk8266.c
[LINK]
   text    data     bss     dec     hex filename
  12784      10   70408   83202   14502 image.elf
[MAKEDISK] DISK_A.DSK
[MAKEDISK] DISK_B.DSK
[MAKEDISK] DISK_C.DSK
[MAKEDISK] DISK_D.DSK
[MAKEDISK] DISK_E.DSK
[MAKEDISK] DISK_F.DSK
[MAKEDISK] DISK_G.DSK
[MAKEDISK] DISK_H.DSK
[MAKEDISK] DISK_I.DSK
[MAKEDISK] DISK_J.DSK
[MAKEDISK] DISK_K.DSK
[MAKEDISK] DISK_L.DSK
[MAKEDISK] DISK_M.DSK
[MAKEDISK] DISK_N.DSK
[MAKEDISK] DISK_O.DSK
[Z80ASM] BOOT.Z80
[Z80ASM] BIOS.Z80
[Z80ASM] BDOS.Z80
[Z80ASM] CCP.Z80

...so with xxd from package vim-common it looks ok now.

I'm still stuck with uploading:

[UPLOAD] disks/DISK_A.DSK to 0x3c0000
[UPLOAD] disks/DISK_B.DSK to 0x381700
Traceback (most recent call last):
  File "/opt/esp-open-sdk/esptool/esptool.py", line 1270, in <module>
    main()
  File "/opt/esp-open-sdk/esptool/esptool.py", line 1181, in main
    operation_func(esp, args)
  File "/opt/esp-open-sdk/esptool/esptool.py", line 871, in write_flash
    flasher.flash_write(address, image, not args.no_progress)
  File "/opt/esp-open-sdk/esptool/esptool.py", line 574, in flash_write
    assert addr % self._esp.ESP_FLASH_SECTOR == 0, 'Address must be sector-aligned'
AssertionError: Address must be sector-aligned
Makefile:224: recipe for target 'writediskB' failed
make: *** [writediskB] Error 1
$ /opt/esp-open-sdk/esptool/esptool.py version
esptool.py v1.2
1.2

Is my esptool.py too old?

The Minion I'm trying to flash is a NodeMCU-Devboard-v0.9 (ESP-12 + CH340) and I don't think he's the culprit.

The ESP monitor should show the disassembled Z80 code while single stepping

This might cause the general cp/m code crashes and two of the zexall tests to fail.

The DJNZ opcode emulation used a plain char to calculate the relative jump and failed due to this.

Just curious but is there any reason why this wouldn't work with wifi & full mem cp/m & all the disk images on an ESP32?

The pre-population of the disks have an empty N-disk and some assembly codes in the O-disk,
but in wifi mode the O-disk is mapped as the N-disk thus making the data in the O-disk not accessible.

Move the data in O: to N: and let O be empty in both NOSDK and WIFI modes instead

I flashed the pre-release v0.4, but couldnt use XMODEM v2.4 on drive M: to transfer files via XMODEM and the CON:-device :( The v2.4 does hang at the start of the XMODEM-Transfer.

Also your XR.COM v0.1 from drive A: get stuck at the beginning of the transfer :(

After different other attempts I found a way to transfer/replace v2.4 of XMODEM with the actual v2.7 of XMODEM, which can transfer files via XMODEM/CON: with the cpm8266-emulation.

Maybe the author can place this packet somewhere on github in the cpm8266-section or in the pre-relaese section near by the v0.4-pre-release :)

Thank you in advance!

XMODEM27_for_CPM_ESP8266.zip

In different Linux (armbian/devuan) systems I do get a error 2 after:
git clone --recursive https://github.com/pfalcon/esp-open-sdk.git cd esp-open-sdk make

showing
Now configured for "xtensa-lx106-elf" make[2]: Verzeichnis „/home/guido/esp-open-sdk/crosstool-NG“ wird verlassen sed -r -i.org s%CT_PREFIX_DIR=.*%CT_PREFIX_DIR="/home/guido/esp-open-sdk/xtensa-lx106-elf"% .config sed -r -i s%CT_INSTALL_DIR_RO=y%"#"CT_INSTALL_DIR_RO=y% .config cat ../crosstool-config-overrides >> .config ./ct-ng build make[2]: Verzeichnis „/home/guido/esp-open-sdk/crosstool-NG“ wird betreten [ERROR] You must NOT be root to run crosstool-NG [00:00] / ct-ng:152: die Regel für Ziel „build“ scheiterte make[2]: *** [build] Fehler 1 make[2]: Verzeichnis „/home/guido/esp-open-sdk/crosstool-NG“ wird verlassen ../Makefile:133: die Regel für Ziel „_toolchain“ scheiterte make[1]: *** [_toolchain] Fehler 2 make[1]: Verzeichnis „/home/guido/esp-open-sdk/crosstool-NG“ wird verlassen Makefile:129: die Regel für Ziel „/home/guido/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc“ scheiterte make: *** [/home/guido/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc] Fehler 2

Any idea?
Thanks in advance! :)

master/code/dist/readme.txt#L6 ... current version is not started via EMON.

master/code/dist/readme.txt#L25-L29 ... still refers to cpm8266_01.bin.

master/code/dist/readme.txt#L48 ... now mention the autobauder?

master/code/dist/readme.txt#L61-L72 ... "screenshot" is from cpm8266_01.bin, so still shows EMON and "cpm8266 v0.1" as startup message.