Project

General

Profile

Feature #76

Merge down to trunk

Added by foft 9 months ago. Updated 5 days ago.

Status:
In Progress
Priority:
High
Assignee:
-
Start date:
10/05/2018
Due date:
% Done:

0%


Description

Several requests to get some of these features back up and running on the mist.

History

#1 Updated by foft 9 months ago

  • Tracker changed from Bug to Feature

#2 Updated by foft 9 months ago

  • Subject changed from MIST backport to Merge down to trunk

#3 Updated by foft 9 months ago

  • Priority changed from Normal to High

Keen to get this work back on the mainline.

#4 Updated by foft 9 months ago

This will probably break many (other platform) core builds on trunk in the short term...

#5 Updated by foft 8 months ago

  • Status changed from New to In Progress

Made an svn copy of existing trunk (branches/releases/trunk_20181013_premerge)
Also made a backup of lots of random local stuff on my trunk checkout!
Going to merge down the entire eclaireXL branch and start working on trunk.
This will break a lot, since there are a lot of specific eclaire firmware features for instance.

#6 Updated by foft 8 months ago

Easy part done, merged down.

For now I branched firmware into firmware_eclairexl and firmware_legacy (for other platforms).
However common is probably incompatible with the other core builds to some degree... Probably nothing too major.

#7 Updated by foft 4 months ago

Gy├Ârgy spurred me on by fixing the mist for 5200.

I've merged his changes.

I've also made a start at getting other cores building. So far mcc216 builds. Firmware is going to need merging to make these work though, but having them build is a good step...

#8 Updated by foft 4 months ago

Allowed targets without usb to build. The code expected the 48MHz clock to generate the 1MHz tick, which needed to be more accurate for atx support.

#9 Updated by foft 4 months ago

Got the legacy firmware to work against the new hardware. At least the mcc216 is working in a8 mode...

Unfortunately need to save a few hundred bytes to fit atx support.

#10 Updated by foft 4 months ago

Trying to program 5200 ntsc... getting there, but not quite!

#11 Updated by foft 4 months ago

5200 ntsc is working on mcc.
Trying to merge the two firmwares...

So menu structure is different, flash support and pll support. Commenting those and it builds, except its too large for some targets (>32k).

Probably need to write a simple generic menu thing and use it instead of this massive hack.

#12 Updated by foft 3 months ago

Trying to get the 40k eclaire rom working 'as is' on the mcc now.
All building ... but ...its erasing my sd card! Hmmm, what is going on here...

#13 Updated by foft 3 months ago

Now trying to get Chameleon 1 back up and running ... before moving onto Chameleon 2. So far got the Atari screen but sio seems broken for some reason.

#14 Updated by foft 3 months ago

sio on chameleon was just a missed new pin (io clock).
Done most of chameleon2 wiring with the new helpers... Just a few things remain then I can try it:
  • 8MHz->50MHz in plls
  • Assign pins in qsf
  • Solder on jtag
  • Change device to cyclone 10 in qsf
  • Cross fingers!

#15 Updated by foft 3 months ago

Getting closer!
  • 8MHz->50MHz in plls
  • DONE:Assign pins in qsf
  • Solder on jtag
  • DONE:Change device to cyclone 10
  • Install cyclone 10 support to quartus
  • Cross fingers!

#16 Updated by foft 3 months ago

Enough for today!

  • 8MHz->50MHz in plls
  • DONE:Assign pins in qsf
  • Solder on jtag
  • DONE:Change device to cyclone 10
  • DONE:Install cyclone 10 support to quartus
  • Upgrade all ip to cyclone 10
  • Cross fingers!

#17 Updated by foft about 2 months ago

Continuing chameleon bring up on #78

#18 Updated by foft 26 days ago

I think chameleon 1 and chameleon 2 are good. firmware_eclaire is running on them and also on the eclaire.

Heading back to some other targets soon.

#19 Updated by foft 22 days ago

Building the mcc216 with this latest firmware + plumbing changes. Realized the scandoubler will not fit in the memory at the same time as this larger firmware, arg!

#20 Updated by foft 22 days ago

freezer 1024 1
antic 1536 1
scandoubler1 14600 2
scandoubler2 14600 2
zpu rom 327680 40
zpu ram 16384 2
" 16384 2
" 16384 2
" 16384 2
sio fifo rx 3840 1
sio fifo tx 2048 1
usb fifo rx 512 1
usb fifo tx 512 1

total ... 58. Perhaps I can specify the fifo to use logic elements instead. Or back to shrinking that zpu rom... Really should be able to get it into 32k!

#21 Updated by foft 15 days ago

Tried building with riscv and the firmware size dropped from 37KB to <32KB. Which is great! So might need to reactivate the zpu->riscv plan...

#22 Updated by foft 13 days ago

That was with 64-bit riscv, switched to the 32-bit version and its bigger: 39512

#23 Updated by foft 13 days ago

-flto gets me to 33244

#24 Updated by foft 10 days ago

Experimenting with replacing the menu with a simple structure/code approach, should cut code size somewhat.

#25 Updated by foft 7 days ago

Haha, working and much neater, but 300 bytes more

#26 Updated by foft 7 days ago

Probably split into too many functions, adding function call overhead...

Anyway should probably target some of these big items:
nm --print-size --size-sort --radix=d ECLAIREXL.elf | less

0007457 00000527 T tfp_format
00012850 00000571 T flash_rpd
00003149 00000617 t follow_path
00003760 00000627 T pf_mount
00032220 00000633 T usb_dispatchPktWithData
00018367 00000656 T handleRead
00009291 00000685 T display_menu
00005062 00000720 T pf_readdir
00033905 00000769 T usb_poll
00016633 00000915 T set_drive_status
00006091 00001083 T file_selector
00019667 00001179 T loadAtxSector
00029689 00001464 T parse_report_descriptor
00058972 00001568 B devices
00021992 00001880 t usb_hid_parse_conf
00023478 00003296 t usb_hid_init
00026289 00004307 t usb_hid_poll

#27 Updated by foft 5 days ago

Need to save 6k. Lots of complexity in the USB, largely for supporting the custom mcc joysticks. I could comment them but its mostly for the MCC that I have memory issues so I want to support the official joypads!

Idea: Really USB pollling is simple, send an in request then a byte stream is returned with some bits set/unset (buttons) and signed/unsigned values (axes). Could store a file with a mapping in per vid/iid and have simple code to apply. So we simplify structure and use files for custom devices.

#28 Updated by foft 5 days ago

Perhaps I could even write byte stream to a hardware buffer and have regs for axis offset, axis type (signed/unsigned), button offset. Then poll becomes just sending an in request and writing to this hardware buffer. init becomes initializing these regs from a vid named file (optional) or decoding HID.

#29 Updated by foft 5 days ago

Perhaps a state machine to do the in request too, then I do not even need to call poll.

Also available in: Atom PDF