<Xark>
emeb_mac: Hello. 6502 project going well. I am still playing with it. I fixed a minor bug in vga font generation and am working on improving the video firmware etc.
<emeb_mac>
Xark: what was wrong with vga fonts (looked OK to me)?
<mithro>
> So, a problem with binding C++ is that templates are basically glorified macros. The work is all at compile time. So how are you supposed to call it from Python, where everything happens at runtime? In order to be able to use any templated function or type, you'd need to embed a C++ interpreter to handle the template definitions or something. Someone thought all that and then also thought "yes, that is a great idea".
* Xark
cringes a bit...
<Xark>
emeb_mac: It was not displaying the first text line (i.e., 100 chars skipped) and the top line started at the 2nd line of the glyphs. Initializing the first line and char line to "all ones" fixed this (like they pre-incremented).
<Xark>
emeb_mac: It was fine since OSI video code had large border
<emeb_mac>
Xark: haha, ok. Gotta admit that I didn't spend a lot of time on boundary conditions.
<Xark>
emeb_mac: When I was playing around in firmware with 2D cursor and a few things I noticed this.
<emeb_mac>
Xark: Yep - that would show it. The OSI text output code is so crude you'd probably not notice what's going on with the top line.
<Xark>
emeb_mac: Yep. I added color emory scrolling and output. I also have some ideas for a slightly improved memory layout.
<emeb_mac>
Xark: Nice. Having the color scroll with the glyphs would be a big plus. And 2D access is nice too.
<Xark>
emeb_mac: The fun (but slightly ambitious) thing would be to customize basic wth some cool graphics commands. Doing it with pokes from BASIC is kind of disasapointing (even at 10Mhz).
<emeb_mac>
Xark: Absolutely!
<Xark>
emeb_mac: I am eyeing that "build your own BASIC" project. :)
<emeb_mac>
Xark: Indeed - that seems like the logical place to start.
<Xark>
emeb_mac: Yeah, now that I look at disassembly of original OSI ROM, I see what a horrible hack it was. :)
<emeb_mac>
Xark: haha, yeah. there are a lot of really silly shortcuts. Bill Gates is a hack. :)
<emeb_mac>
Probably why the folks at Commodore gave up on MS Basic and rolled their own for the later models
<Xark>
emeb_mac: A super simple "blitter" would be pretty easy and cool too (even if like memcpy with custom increment and line modulo).
<emeb_mac>
Xark: yep - that's one of the first things that many folk add to such systems
<emeb_mac>
Just a mem to mem DMA engine.
<Xark>
emeb_mac: Honestly, it might be easier to get that working (perhaps with line draw) than getting fast optimized 6502 code for graphics...
<emeb_mac>
Xark: heh - all depends on what you're more comfortable with - 6502 assy or Verilog.
* Xark
wrote 6502 game code for Apple, Atari and Commodore back in the day...but time consuming
<emeb_mac>
yep - I added a TMS9918 to my OSI system and wrote a graphics lib for it - lines, circles, area fills, etc.
<emeb_mac>
but never went as far as doing games.
<Xark>
emeb_mac: I am a tiny bit spoiled by for too much 6502, and I am most comfortable with VHDL. However, I am getting better at Verilog (and good excuse to do something a bit trickier),
<Xark>
emeb_mac: Very cool.
<emeb_mac>
Xark: do you have this on a github somewhere so I can follow along with your system?
* Xark
links https://justpaste.it/uop I have done quite a few games (several 6502 ones shown there even...)
<emeb_mac>
Xark: wow - a pro.
<Xark>
emeb_mac: I have github, but I haven't put up5k_vga version up. I recently "broke" the firmware... I think I will back off on 2D and get it back to working (with improvements).
<emeb_mac>
Xark: heh - been there. Make too many changes w/o testing and "whoops". Then have to back up to a working system and take smaller steps.
<Xark>
emeb_mac: Still coding games for day job (but consoles are mostly boring slow PCs these days). :)
Bike has quit [Quit: Lost terminal]
<emeb_mac>
Xark: Oh cool. Still having fun with it?
<Xark>
emeb_mac: I can't complain, but sometimes I still do. :)
<emeb_mac>
:)
<emeb_mac>
Xark: I've kind of set that 6502 stuff on the back burner for a while. Working on a client job and also exploring a picorv32 project on the FPGA.
<emeb_mac>
That's a big bigger and a bit slower than the 6502 core, but it's nice to have a good gcc toolchain to code with.
<Xark>
emeb_mac: Neat. I have toyed a bit with PicoRV32 on the IceBreaker. Not 100% positive, but I think it can only use SPRAM, not execute out of it (at least I had issues when trying it). That kind of bummed me.
<emeb_mac>
Xark: hmm... I haven't tried running code in the SPRAM yet. Can't think of why that would matter though, and tnt has definitely had it working.
<Xark>
emeb_mac: Okay, well, may very well be me running afoul of caches or something.
<emeb_mac>
Xark: ah - the systems I've been studying don't have any cache - just minimum configurations of clifford's picorv32.
<Xark>
(I tried to add a ".text.ram" segment that would copy code to RAM in C init - worked for small tests not larger - but hard to debug). :)
<Xark>
emeb_mac: You need pretty minimal just to fit on up5k, I believe. No mult/div and barely with barrel shift.
<emeb_mac>
Debugging is a challenge. I've been running code in iverilog to see what it's doing low-level. That works ok for short/simple stuff.
<Xark>
emeb_mac: However, I thought it read from flash to bram cache (but I may be wrong - or only in fancier configs).
<emeb_mac>
Xark: the picorv32 is just a CPU w/o any fancy memory architectures. As I've got it set up it's running out of BRAM with initial data and using SPRAM for volatile storage.
<Xark>
emeb_mac: Good point, I should say "PicoSoC" (in same tree as PicoRV32 though). :)
<emeb_mac>
but the original systems I've seen do load from flash to some sort of on-chip RAM.
<Xark>
emeb_mac: There was a handy "out of box" IceBreaker make target there (so easy to play with).
<emeb_mac>
Xark: OK - I haven't studied that. I just started mine from scratch (after studying some of tnt's stuff)
<Xark>
emeb_mac: However, still having fun with your 6502 project (and getting used to Verilog and "fast" FPGA toolchain).
<emeb_mac>
Xark: it is nice to get things built so quickly.
<Xark>
emeb_mac: It still seems slow for 10Mhz 6502 though. However, that may be an illusion from 8K of text memory (as much as slow Hi-res). I did try removing ACIA echo etc. (helped a bit).
<Xark>
emeb_mac: I also got it working fine at 72Hz 800x600 (with IIRC 50Mhz dot clock - so 12.5Mhz 6502).
<Xark>
(However, text was fuzzier on my LCD, and no need for faster display - 60Hz is nice)
<emeb_mac>
Yeah - The NTSC system runs the CPU @ 16MHz and definitely feels faster.
<emeb_mac>
but interpreted Basic running on an 8-bit CPU is going to feel slow regardless.
<Xark>
emeb_mac: The scroll is noticably smoother with my firmware changes (even with glyphs added). However, not a biggie with 115,200 baud text output.
<Xark>
emeb_mac: Yeah....one of the companies I wrote games for also made a 3x Apple "speed-up card". Boy did you notice when one day your daily system got to ~3.5Mhz from 1Mhz.
<Xark>
emeb_mac: BASIC was always tearfully slow. Drove me to assembly (and a nice career).
<emeb_mac>
Xark: funny how that works out.
<emeb_mac>
"monitize your enthusiasms"
<fseidel>
Xark: was this Applied Engineering, by any chance?
rohitksingh_work has joined ##openfpga
<Xark>
fseidel: No, McT SpeeDemon which later became the ZipChip. I think I had an AE card in my dev machine though (before theirs worked).
<Xark>
fseidel: SpeedDemon just had ~4KB of fast cache, AE had whole 64KB of faster RAM (IIRC).
* Xark
notes McT was originally McToy and did embedded toys like Entex Adventure Vision (with 8048 and 1D row of LEDs and spinning mirror).
<fseidel>
neat! the IIGS was a really awesome machine
<fseidel>
shame it didn't get the attention it deserved
<Xark>
fseidel: Yeah. It came out a bit late and was kind of hobbled by Apple (to not throw any shade at Mac).
<Xark>
fseidel: I was on to Amiga by then...
dj_pi has quit [Ping timeout: 245 seconds]
emeb_mac has quit [Ping timeout: 248 seconds]
cpresser has quit [Ping timeout: 248 seconds]
cpresser has joined ##openfpga
Miyu has joined ##openfpga
rohitksingh has joined ##openfpga
Asu has joined ##openfpga
Bob_Dole has quit [Ping timeout: 276 seconds]
m4ssi has joined ##openfpga
finsternis has quit [Excess Flood]
finsternis has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 268 seconds]
futarisIRCcloud has joined ##openfpga
Hoernchen has quit [Ping timeout: 246 seconds]
Hoernchen has joined ##openfpga
Asu has quit [Remote host closed the connection]
Asu has joined ##openfpga
Bob_Dole has joined ##openfpga
Bob_Dole has quit [Ping timeout: 276 seconds]
Bob_Dole has joined ##openfpga
OmniMancer has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has quit [Ping timeout: 245 seconds]
somlo has quit [Remote host closed the connection]
somlo has joined ##openfpga
Bob_Dole has quit [Ping timeout: 276 seconds]
Bob_Dole has joined ##openfpga
somlo has quit [Ping timeout: 258 seconds]
somlo has joined ##openfpga
finsternis has quit [Excess Flood]
finsternis has joined ##openfpga
indy_ has joined ##openfpga
mifune has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
wpwrak has quit [Ping timeout: 245 seconds]
wpwrak has joined ##openfpga
rohitksingh has quit [Ping timeout: 272 seconds]
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
vonnieda has joined ##openfpga
<_whitenotifier-3>
[whitequark/Boneless-CPU] whitequark pushed 3 commits to master [+1/-0/±6] https://git.io/fj6Iq
<_whitenotifier-3>
[whitequark/Boneless-CPU] whitequark f92bc04 - gateware.decoder_v3: use ControlEnum.
<_whitenotifier-3>
[whitequark/Boneless-CPU] whitequark 6968ffe - gateware: use MultiControlEnum.
azonenberg_work has quit [Ping timeout: 245 seconds]
mifune has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
<_whitenotifier-3>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+1/-0/±5] https://git.io/fj6LB
<_whitenotifier-3>
[whitequark/Boneless-CPU] whitequark b793d1b - gateware: use MultiControlEnum.
OmniMancer has quit [Quit: Leaving.]
pie__ has quit [Ping timeout: 246 seconds]
emeb has joined ##openfpga
azonenberg_work has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
oeuf has quit [Ping timeout: 272 seconds]
<ovf>
whitequark: is it ok if i pm you?
<whitequark>
sure
Asu has joined ##openfpga
oeuf has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
Miyu has quit [Ping timeout: 258 seconds]
<Sprite_tm>
Hey guys, I don't think there's a chance to synthesize the PULP Ri5cy CPU as it's written in SystemVerilog, right? Or is there some trick to allow Yosys to understand that?
<Sprite_tm>
*guys (m/f)
<mithro>
Latest RapidWright Release -> Support for building a shared object library from RapidWright using GraalVM to call RapidWright from C/C++
<TD-Linux>
Sprite_tm, basically, no. you can edit it to be a compatible set of verilog with some difficulty, probably
<Sprite_tm>
Hm, that's unfortunate.
<Sprite_tm>
Blerg, no easy fix... it also uses 2d arrays of in/outs... which to my knowledge Yosys also doesn't get.
<Sprite_tm>
Verific seems an option, but the website seems like a 'if you have to ask, you can't afford it' vibe.
rohitksingh_ has joined ##openfpga
Richard_Simmons has joined ##openfpga
rohitksingh_ has quit [Ping timeout: 245 seconds]
Dolu has quit [Ping timeout: 246 seconds]
rohitksingh has quit [Ping timeout: 258 seconds]
Bob_Dole has quit [Ping timeout: 276 seconds]
<emeb>
interesting - seems that the riscv gcc doesn't have something that works like function-sections and gc-sections to strip out unused functions.
<tnt>
emeb: enable lto
linzhi-sonia has quit [Quit: Lost terminal]
<emeb>
tnt - that did it. thx
<emeb>
interesting to see what that does to the resulting code. some aggressive in-lining for functions that are only called once.
<tnt>
Well, yeah, no point in paying the cost of a call if you can merge the function without size overhead :p
<q3k>
Sprite_tm: this uses verific and comes with free licenses for oshw
<emeb>
tnt: for some reason when I add -gc-section my code size goes to zero. I guess there's something that needs to change in the linker script?
<whitequark>
you don't need --gc-sections with lto
<tnt>
whitequark: I remember I left it there for a reason ... but doesn't come back to me ATM ...
<tnt>
emeb: yeah, you need the entry point specified as "keep".
Asu has quit [Quit: Konversation terminated!]
futarisIRCcloud has joined ##openfpga
pie_ has joined ##openfpga
<emeb>
here's a silly question regarding iCE40 hard IP cores on the system bus: documentation implies all 4 cores (2 ea SPI & I2C) are on the same system bus. However, the module ports imply separate SBDATO and SBACKO for each instance.
<emeb>
Are the all muxed onto the same SBDATO and SBACKO lines?
<emeb>
Or does the user need to add muxing?
<tnt>
emeb: I'm pretty sure you need to add your own. They definitely seem to be different wires in the fpga.
<emeb>
tnt: thanks - that makes sense.
Bike has joined ##openfpga
<tnt>
emeb: But yeah, I also wondered the same (at some point I thought there was only 1 system bus since they seemd to put the peripheral at != addresses), but I think it's just so that you can just connect them all together without any added decode logic.
<tnt>
And for the ACK you can just OR them and the DATO, maybe OR them as well (not sure if they output 0 when not selected).
<emeb>
tnt: yes - I was wondering that too.
<tnt>
emeb: make sure to report when you tested :p
<emeb>
tnt: of course.
<emeb>
hmm... seems that nextpnr doesn't know how to pack more than one instance of SB_SPI
<emeb>
values of BUS_ADDR74 != "0b0000" don't work.
<emeb>
Aha - Lattice documentation fail. Legal values of BUS_ADDR74 for SB_SPI are 0b0000 or 0b0010 (not 0b0001)
<emeb>
collision w/ 1st instance of SB_I2C
<emeb>
OR connection seems to work, but I'm only talking to one of the cores ATM
<emeb>
simple async mux based on top 4 bits of sbaddri works too
<emeb>
pro tip - include a default in the case :P
<tnt>
lol
vonnieda has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<mithro>
For those not on twitter - If someone was adding a custom instruction inside an RISC-V CPU but it needed *two* destination registers, how would you think that should be encoded? None of the standard instruction formats seem to allow more than one destination register....
<whitequark>
use two consecutive ones, duh
<emeb>
tnt: 2nd SPI port working fine simultaneously w/ 1st one and using simple OR muxing.
<sorear>
mithro: use a rsN field
<mithro>
whitequark: Oh - as in if rd == 5, then store in 5 and 6?
<kc8apf>
that's how most ISAs deal with that
<whitequark>
mithro: yep
<tnt>
+1 to consecutive ones.
<tnt>
doesn't the mul do that ?
<tnt>
ah no.
emeb has quit [Quit: Leaving.]
<sorear>
I’m thinking more like the umull encoding