00:48 <d1b2> <brainstorm> > yes, then it's just not possible to write, you are right @whitequark#0000 Thanks for the feedback and insight folks! I'm not sure I totally understand why write is not possible though? :/

00:58 <whitequark> brainstorm: okay so, my brain wasn't turned on this morning, sorry about that (also i apologize to tnt and noopwafel)

00:59 <whitequark> right now the applet lets you choose between address pins directly on glasgow and address pins connected to some shift registers

00:59 <whitequark> data pins have to be connected directly to glasgow

00:59 <whitequark> because revC only has 16 channels, and your flash also has 16 data pins, this is a problem

00:59 <whitequark> revD will have 32 channels, but it's merely in the design phase

01:00 <whitequark> what could be done in principle is two things

01:00 <whitequark> - reading the flash one half at a time

01:00 <whitequark> but you can't write the flash that way because there aren't byte enables

01:01 <whitequark> (SRAM has byte enables, 29x flash instead has byte mode, yours has neither of these mechanisms. you always write 16 bits, and these 16 bits are taken frmo 16 data pins)

01:01 <whitequark> - extending the applet to mux data pins back to glasgow similar to the way address pins are handled

01:01 <whitequark> this presents some not entirely trivial gateware changes, but is possible in principle

01:29 <d1b2> <brainstorm> @whitequark Thanks a lot for taking the time to explain. For practical/time constraint issues I will have to go for the FlashCAT for now then, unfortunately (since I 1000% prefer the toolchain that the Glasgow has :/).

02:00 <d1b2> <h0m3us3r> @brainstorm can you show me a screenshot where it says that flashcat supports that specific chip?

02:01 <d1b2> <brainstorm> Sure

02:01 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/741476143458418818/Skarmavbild_2020-08-08_kl._12.01.13.png

02:12 <d1b2> <h0m3us3r> Oh, but you need to use Mach1 or XPORT, not the one you linked to earlier

02:17 <d1b2> <h0m3us3r> https://cdn.discordapp.com/attachments/613461005392936961/741480225011138560/EXTIMG_3.png

02:17 <d1b2> <h0m3us3r> They have this photo posted on the adapters page

02:18 <d1b2> <h0m3us3r> But I couldnt find it anywhere

02:19 <d1b2> <brainstorm> Mach1 with TSOP56: > @h0m3us3r https://www.embeddedcomputers.net/products/FlashcatUSB_Mach1/ @brainstorm Mach1 with TSOP56 type A, as referred to before

02:19 <d1b2> <brainstorm> https://www.embeddedcomputers.net/products/FlashcatUSB_Mach1/IMG_3_SMALL.png

02:20 <d1b2> <h0m3us3r> > I wonder how FlashCat does it: https://www.embeddedcomputers.net/products/FlashcatUSB/ @brainstorm

02:20 <d1b2> <brainstorm> Sorry folks for non-glasgow related stuff

03:05 <whitequark> no problem, we discuss all sorts of stuff here

03:15 <d1b2> <brainstorm> Thanks @whitequark ... funny turn of events: after re-inquiring support to make sure this particular IC is supported (as I was examining the schematics), it seems it's actually not supported but they'll build a shield for it soon (~7days).

03:15 <d1b2> <brainstorm> https://cdn.discordapp.com/attachments/613461005392936961/741494772882997258/Skarmavbild_2020-08-08_kl._13.13.46.png

03:16 <d1b2> <brainstorm> Now I'm curious about the "non trivial" Glasgow gateware changes you mentioned... checking code and trying to assess how involved that might be.

03:24 <whitequark> brainstorm: the main problem is bi-directionality of the data bus

03:24 <whitequark> for output only it's relatively easy and can be done just how it's done for the address pins

13:13 <_whitenotifier-b> [glasgow] Success. The Travis CI build passed - https://travis-ci.org/github/GlasgowEmbedded/glasgow/builds/716106758?utm_source=github_status&utm_medium=notification

22:02 <awygle> is "Glasgow debug tool" the official name? wasn't it "interface explorer" at one point?

22:04 <awygle> oh that was the crowdsupply campaign's name